Erkennung von Quellkodeduplikaten in WSN ...moeller/publist-sts-pw-and-m/...Erkennung von Quellkodeduplikaten in WSN-Routingprotokollen mittels Klondetektoren Bachelorarbeit vorgelegt

Erkennung von Quellkodeduplikaten inWSN-Routingprotokollen mittels

Klondetektoren

Bachelorarbeit

vorgelegt von Yi TangFachbereich: Institute for Software SystemsFachrichtung: SoftwaresystemeBetreuer: Prof. Dr. Sibylle Schupp,

Institute for Software SystemsZweitbetreuer: Prof. Dr. Andreas Timm-Giel,

Institute for Communication NetworksAbgabedatum: 27. August 2010

Technische Universität Hamburg-Harburg

Inhaltsverzeichnis

1. Einleitung 11.1. Hintergrund dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3. Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Grundlagen 32.1. WSN und Routingprotokolle . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1. Betriebssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.1.1. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.2. Routingprotokolle für WSN . . . . . . . . . . . . . . . . . . . . . 72.1.2.1. Untersuchte Protokolle . . . . . . . . . . . . . . . . . . . 9

2.2. Klone und Klonerkennung . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.1. Code-Klone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.1.1. Klonpaar . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.1.2. Klonklasse . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.1.3. Klontypen . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.2. Klonerkennungsprozess . . . . . . . . . . . . . . . . . . . . . . . . 202.2.3. Klonerkennungsverfahren . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.3.1. Textbasierte Verfahren . . . . . . . . . . . . . . . . . . . 212.2.3.2. Tokenbasierte Verfahren . . . . . . . . . . . . . . . . . . 222.2.3.3. Baumbasierte Verfahren . . . . . . . . . . . . . . . . . . 232.2.3.4. Metrikbasierte Verfahren . . . . . . . . . . . . . . . . . . 242.2.3.5. Graphenbasierte Verfahren . . . . . . . . . . . . . . . . . 25

2.2.4. Ausgewählte Klondetektoren . . . . . . . . . . . . . . . . . . . . . 252.2.4.1. CCFinder . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.4.2. Ccdiml . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2.4.3. Deckard . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3. Beschreibung des Tests 293.1. Teststruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1.1. Testgegenstand . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1.2. Testwerkzeug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2. Vorbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2.1. NesC nach C Transformation . . . . . . . . . . . . . . . . . . . . 31

3.2.1.1. Methode . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

ii

Inhaltsverzeichnis

3.2.1.2. Transformationsregeln . . . . . . . . . . . . . . . . . . . 333.2.2. Bestimmung der Testparameter . . . . . . . . . . . . . . . . . . . 35

3.2.2.1. CCFinder . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2.2.2. Deckard . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.2.3. Ccdiml . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.2.2.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . 44

3.2.3. Kategorisierung der Routing Protokolle . . . . . . . . . . . . . . . 443.3. Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4. Auswertung der Testergebnisse 474.1. Auswertungsverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2. Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2.1. Statistik auf der Kategorie-Ebene . . . . . . . . . . . . . . . . . . 484.2.2. Ähnlichkeitsgrade von Protokollen . . . . . . . . . . . . . . . . . . 494.2.3. Verteilung der Klone in den Dateien . . . . . . . . . . . . . . . . 53

4.2.3.1. MintRoute, Route . . . . . . . . . . . . . . . . . . . . . 534.2.3.2. Dip und Dhv . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3. Beurteilung der Klondetektoren . . . . . . . . . . . . . . . . . . . . . . . 564.3.0.3. Ein Beispiel aus dem Resultat . . . . . . . . . . . . . . . 60

5. Zusammenfassung und Ausblick 62

A. Detaillierte Ergebnisse für das Parametertuning der Klondetektoren 64A.1. CCFinder Parameterset Tuning . . . . . . . . . . . . . . . . . . . . . . . 64A.2. Ccdiml Parameterset Tuning . . . . . . . . . . . . . . . . . . . . . . . . . 66A.3. Deckard Parameterset Tuning . . . . . . . . . . . . . . . . . . . . . . . . 68A.4. Protokolle, deren Dateien und SLOCs . . . . . . . . . . . . . . . . . . . . 70

iii

1. Einleitung

1.1. Hintergrund dieser Arbeit

Wireless-Sensornetzwerke (WSN) haben sich in den letzten Jahren zu einem sehr aktiv-en Forschungsgebiet entwickelt. Ein solches Sensornetz besteht aus einer Vielzahl klein-er Sensorknoten, die drahtlos miteinander kommunizieren und ihre Umwelt mit Hilfeihrer Sensoren beobachten können. Wie in jeder Art von Netzwerken stellt das Routingeine essentielle Domain dar. Aufgrund verschiedener Anwendungsgebiete, verschiedenerPlattformen und unterschiedlicher Funktionalitäten und Netzwerkarchitekturen wurdenbereits zahlreiche Routingtechniken und Routingprotokolle entwickelt, und viele Rout-ingprotokolle wurden aufeinander aufgebaut um zusätzliche oder verbesserte Funktion-alitäten zu erlangen. Dabei können sich Funktionalitäten duplizieren oder ähneln, abertrotzdem immer neu implementiert werden.

Es ist daher für die Entwickler von Interesse, die gemeinsamen oder ähnlichen Funk-tionalitäten zu abstrahieren und modularisieren um dann ein Protokoll entwickeln zukönnen, welches durch einfachen Austausch der Module über neue Funktionalitäten ver-fügen kann. Die funktionellen Gemeinsamkeiten der zahlreichen Routingprotokolle kön-nen zwar durch manuelle Analyse der Quell-Codes erfasst werden, aber das ist sichernicht der effizienteste Weg dafür.

1.2. Aufgabenstellung

Ziel dieser Arbeit ist es daher, zahlreiche Routingprotokolle auf systematische, möglichstautomatisierte Weise auf duplizierte oder ähnlichen Funktionalitäten zu untersuchen.

1

1.3 Überblick

Als das Wertzeug für diesen Zweck stellen die Klonerkennungs-Techniken und Klonde-tektoren eine interessante Möglichkeit dar. Es gab zwar zahlreiche Anwendungsfälle, wogroße Softwaresystemen mit Klondetektoren zwecks Restrukturierung auf Code-Kloneuntersucht wurden, gibt es jedoch bislang keine bekannte Verwendung im Gebiet derUntersuchung von Routingprotokollen von WSN.

Daher wird in dieser Arbeit zunächst die Einsetzbarkeit der Klonerkennungs-Technikenund Klondetektoren untersucht und anschließend 19 von Entwicklern bereitgestellteRoutingprotokolle mit Hilfe von ausgewählten Klondetektoren auf duplizierten Codeund Funktionalitäten untersucht. Das Augenmerk wurde hierbei auf Codefragmentegerichtet, die sich später eventuell vom Entwickler leichter modularisieren lassen, z.B. insich abgeschlossene funktionelle Codeblöcke wie eine Funktionsdefinition oder eine län-gere Sequenz von Statements, die einen komplexen Verarbeitungsschritt oder eine Logikim Ablauf einer Funktion darstellen.

1.3. Überblick

Die vorliegende Arbeit gliedert sich in fünf Kapitel.

Nach dieser Einleitung folgt ein Kapitel mit einer Erläuterung des theoretischen Hinter-grunds der Thematik. Darin werden die Grundlage von Wireless-Sensornetzwerken undRoutingprotokollen vorgestellt, sowie ein Überblick über die grundlegenden Ansätze zurKlonerkennung gegeben.

Im 3. Kapitel werden der Aufbau des Tests, die getroffenen Vorbereitungen und dietatsächliche Umsetzung erläutert.

Im 4. Kapitel erfolgt die Auswertung der Testergebnisse.

Im letzten Kapitel wird eine Zusammenfassung, sowie ein Ausblick auf eine möglichevertiefte Untersuchung gegeben.

2

2. Grundlagen

In diesem Kapitel werden zuerst die Grundlagen von Wireless-Sensornetzwerken vermit-telt. Es soll dabei gezeigt werden, warum die Untersuchung an den Routing-Protokollenvon Interesse ist. Anschließend werden die Klonerkennungs-Techniken und die für dieseArbeit verwendete Klondetektore vorgestellt.

2.1. WSN und Routingprotokolle

Definition: WSN wird verwendet um physikalische Größen zu erfassen und so die Umge-bungsbedingungen abzubilden. Die physikalischen Größen umfassen beispielsweise Tem-peratur, Schall, Vibration, Druck oder Bewegung. Jedes Gerät, ein Mote, kann einen odermehrere Sensoren besitzen, je nach zu überwachenden physikalischen Größen. Zusätzlichzu dem eigentlichen Sensor verfügt jedes Mote über eine Sende- und Empfangseinheitfür die drahtlose Kommunikation, einen Mikrokontroller und die Energieversorgung-seinheit, üblicherweise eine Batterie. Ein zentrales Gateway (die Basisstation) stellt dieSchnittstelle zwischen den Motes und dem User dar. Die Messdaten von den Motes wer-den per drahtloser Kommunikation an die Basisstation übermittelt, welche die Datendem Benutzer für weitere Erfassung, Verarbeitung und Analyse zur Verfügung stellt.

WSN ist ursprünglich aus militärischen Interessen entwickelt worden, findet aber im-mer mehr Anwendungen in industriellen und zivilen Bereichen. Je nach Anwendungsbe-darf können unterschiedlichste Motes in Frage kommen. Es kann die Größe von einemStaubkorn bis zu einem Schuhkarton haben, oder von ein paar Cent bis zu Hundertevon Euros kosten.

3

2.1 WSN und Routingprotokolle

2.1.1. Betriebssysteme

Die Betriebssysteme für WSN sind nicht so kompliziert wie die handelsüblichen Betrieb-ssysteme für PCs, weil sie für die speziellen Anforderungen der Applikationen der Sen-sornetzwerken und die speziellen Hardwareplattformen konzipiert sind. Beispielsweisebenötigen die Applikationen häufig keine Interaktion mit dem User und bieten auchkein Interface dafür an. Zudem machen die strenge Einschränkung an Ressourcen, z.B.Arbeitsspeicher, Mechanismen wie virtueller Speicher unnötig oder nicht realisierbar.

Es wurden bereits zahlreiche Betriebssysteme für WSN entwickelt. Sie unterscheidensich beispielsweise hinsichtlich verwendeter Programmiersprache, Softwarearchitekturund Realzeitunterstützung. TinyOS [16] ist in nesC [19] programmiert, während vieleandere wie Contiki [25], MANTIS [47], SOS [48] in C programmiert sind. Und währendTinyOS, Contiki und SOS ereignisgesteuerte Architektur verwenden, setzen MANTISund Nano-RK[49] auf präemptives Multithreading.

Im Rahmen dieser Arbeit werden 19 Routingprotokolle aus den drei BetriebssystemenTinyOS 1.x [16], TinyOS 2.x [16] und Contiki und den zwei Projekten SensorScope [12]und WSN Simulator 1.0 (WSNS) [13] untersucht. Da 15 von den 19 Protokollen, diein dieser Arbeit untersucht werden, aus den Betriebsystemen TinyOS 1.x und TinyOS2.x kommen (siehe Tabelle 2.1), und einige Besonderheiten von TinyOS und nesC inder folgenden Arbeit gesondert behandelt werden müssen, wird TinyOS an dieser Stellegenauerer betrachtet.

2.1.1.1. TinyOS

TinyOS ist ein speziell für WSN entwickeltes Betriebssystem. Es ist kein Betriebssystemim traditionellen Sinn, denn es stellt eine Entwicklungsumgebung und ein Program-mierungsframework für eingebettete Systeme dar. So wurde zum Beispiel Sensorscope,ein auf WSN basiertes Messungssystem, dessen Routing-Technik in dieser Arbeit auchuntersucht wird, auf TinyOS entwickelt. TinyOS nutzt eine komponentenbasierte Ar-chitektur (component-based architecture) und ein ereignisgesteurtes Ausführungsmodell(event-driven concurrency model). Um die komponentenbasierte Architektur und dasereignisgesteuertes Ausführungsmodell von TinyOS zu unterstützen wurde die Program-

4


miersprache nesC entwickelt, in welcher wiederum TinyOS (TinyOS 1.x und TinyOS2.x) implementiert werden. Eine typische Applikation ist ungefähr 15K groß, und dasdarunter liegende Betriebssystem ist nur etwa 400 Bytes groß [17].

nesC ist eine Erweiterung der Programmiersprache C mit komponentenbasiertem Konzept.Eine nesC Applikation setzt sich aus Komponenten zusammen, die zu einem einzigen aus-führbaren Programm assembliert werden. Bei einer Komponente handelt sich entwederum ein Modul oder eine Konfiguration. Jede Komponente besteht aus ihrer Spezifika-tion, welche die Interfacenamen festlegt, und deren Implementation. Die Schnittstellendefinieren die Signatur der Komponente. Eine Komponente kann eine oder mehrereSchnittstellen zur Verfügung stellen (Provider) oder verwenden (User). Eine Schnittstellespezifiziert eine Gruppe von Kommandos (commands) und eine Gruppe von Events(events). Der Provider eines Interfaces implementiert die Funktionalität der Komman-dos des Interfaces. Der User eines Interfaces implementiert die Event-Handler für dieEvents des Interfaces (siehe Abbildung 2.1). Damit kann ein einziges Interface komplexeInteraktionen zwischen Komponenten repräsentieren. Die Komponenten sind statischmiteinander über ihre Interfaces verlinkt (siehe Abbildung 2.2). Zur Kompilierung dientder nesC-Compiler Ncc. Ncc ist ein whole-program Compiler. Er erweitert die Toolchainund wird bei einer Kompilierung als erstes aufgerufen. Dabei erzeugt er aus den nesC-Dateien (Endung *.nc) einen C-Quellcode, der anschließend von einem C-Compiler kom-piliert wird.

TinyOS hat drei Arten von Operationen: Kommandos, Events und Tasks. Ein Kom-mando ist eine Anforderung an eine Komponente einen Dienst auszuführen. Das Eventsignalisiert die Beendigung eines Dienstes. Kommando und Event sind keine blockieren-den Operationen. Ein Kommando ruft einen Dienst auf und muss nicht auf seine Beendi-gung warten. Die Beendigung des aufgerufenen Dienstes wird erst später durch ein Eventsignalisiert, so genanntes split phase. Statt einer sofortigen Operation können Komman-do und Event-Handler auch einen Task per post (siehe Abbildung 2.4) in den Schedulereinreihen und später ausführen lassen. Damit bleiben die Kommandos und Events reak-tionsfähig.

Tasks repräsentieren die Nebenläufigkeit innerhalb einer Komponente und kann auchnur auf die Zustandsvariablen innerhalb dieser Komponente zugreifen. Ein Task gehorchtder run-to-completion Regel. Das heißt ein Task darf nicht von einem anderen Task

5


unterbrochen werden. Dies verhindert die Daten-Inkonsistenz unter Tasks. Ein Taskkann jedoch von einem Interrupt-Handler vorübergehend unterbrochen werden. Wenndabei eine gemeinsame Zustandsvariable vom Interrupt-Handler verändert wird, kanndann eventuell Inkonsistenz der Daten verursacht werden. Um die Dateninkonsistenzzu vermeiden wird jedes Update der globalen Zustandsvariablen entweder als ein Taskausgeführt oder wird in einem atomic-Statement eingeschlossen (siehe Abbildung 2.3).Mit atomic wird der wechselseitige Ausschluss im TinyOS implementiert. Während einatomic-Statement ausgeführt wird, werden die Interrupts ausgeschaltet.

. . .module MultiHopEngineM {

p r o v i d e s {i n t e r f a c e StdControl ;i n t e r f a c e Receive [ uint8_t i d ] ;i n t e r f a c e Send [ uint8_t i d ] ;

. . .}u s e s {

. . .i n t e r f a c e StdControl as SubControl ;i n t e r f a c e CommControl ;i n t e r f a c e StdControl as CommStdControl ;i n t e r f a c e SendMsg [ uint8_t i d ] ;

}}

implementation {

. . .

command r e s u l t _ t StdControl . s t a r t ( ) {c a l l CommStdControl . s t a r t ( ) ;c a l l SubControl . s t a r t ( ) ;return c a l l CommControl . setPromiscuous (TRUE) ;

}

. . .

event r e s u l t _ t SendMsg . sendDone [ uint8_t i d ] ( TOS_MsgPtr pMsg , r e s u l t _ t s u c c e s s ){

i f (pMsg == FwdBufList [ iFwdBufTail ] ) {iFwdBufTail++; iFwdBufTail \%= FWD_QUEUE_SIZE;

} e l s e {s i g n a l Send . sendDone [ i d ] ( pMsg , s u c c e s s ) ;

}return SUCCESS ;

}

. . .

}

Abbildung 2.1.: Codeabschnitte austinyos-1.x/tos/lib/MintRoute/MultiHopEngineM.nc.Ein Beispiel für ein Modul

6


. . .c o n f i g u r a t i o n WMEWMAMultiHopRouter {

p r o v i d e s {i n t e r f a c e StdControl ;i n t e r f a c e Receive [ uint8_t i d ] ;i n t e r f a c e I n t e r c e p t [ uint8_t i d ] ;. . .

}

u s e s {i n t e r f a c e ReceiveMsg [ uint8_t i d ] ;

}

}

implementation {

. . .

StdControl = MultiHopEngineM ;Receive = MultiHopEngineM ;Send = MultiHopEngineM ;

. . .

MultiHopWMEWMA. DebugSendMsg −> MultiHopEngineM . Send [ 3 ] ;MultiHopEngineM . ReceiveMsg [ 3 ] −> Comm. ReceiveMsg [ 3 ] ;MultiHopWMEWMA. Leds −> LedsC ;

. . .}

Abbildung 2.2.: Codeausschnitte austinyos-1.x/tos/lib/MintRoute/WMEWMAMultiHopRouter.nc.Ein Beispiel für eine Konfiguration

2.1.2. Routingprotokolle für WSN

Um die Informationen zwischen den physikalisch getrennten Hosts oder Ressourcen ineinem Netzwerk zu teilen, wird eine physikalische Verbindung zwischen den Hosts wieKabel, Links usw. und eine gemeinsame Sprache, so genanntes Protokoll, benötigt, mitdem die Hosts sich verständigen können. Wie die traditionellen Netzwerke, benötigenauch WSN Routingprotokolle um die benötigten Informationen bzw. Daten zwischenden Motes schnell, effektiv und korrekt zu übermitteln.

Eine umfangreiche Studie über diverse Routingprotolle für WSN wurde bereits in [26]1

präsentiert. Hierbei wird ein kleiner Abriss der Klassifizierungsmöglickeiten der Rout-ingprotokolle aus der Arbeit dargestellt.

Klassifizierung nach der Netzwerkarchitektur

1Die Arbeit wurde im Jahr 2004 verfasst, daher können die Informationen die heutige Entwicklung inRoutingprotokolle für WSN nicht vollständig abdecken, dennoch dient sie als einen guten Überblickund Einstieg in Sache Routingprotokolldesign.

7


bool busy ; // g l o b a l

void f ( ) {bool a v a i l a b l e ;

atomic {a v a i l a b l e = ! busy ;busy = TRUE;

}i f ( a v a i l a b l e ) do_somthing ;atomic busy = FALSE ;

}

Abbildung 2.3.: Ein Beispiel für ein atomic-Statement aus [19]. . .

event r e s u l t _ t ATimer . f i r e d ( ) {post SendRouteTask ( ) ;return SUCCESS ;

}

. . .

Abbildung 2.4.: Codeausschnitte aus tinyos-1.x/tos/lib/MintRoute/MultiHopWMEWMA.nc.Ein Beispiel für einen Event-Handler mit Task

• Flaches Routing

• Hierarchisches Routing

• Locationbasiertes Roting

Klassifizierung nach Protokolloperation

• Verhandlungbasiertes Routing (Negotiation-based)

• Multipfadbasiertes Routing

• Querybasiertes Routing

• QosS-basiertes Routing

• Kohärenzbasiertes Routing (Coherent-based)

Klassifizierung nach Routingentscheidung

• Proaktives Routing

8


• Reaktives Routing

• Hybridrouting

• Kooperatives Routing

2.1.2.1. Untersuchte Protokolle

Die 19 Routing-Protokolle wurden aus TinyOS 1.x (TOS1), TinyOS 2.x (TOS2), Contiki2.x (Contiki), SensorScope und WSN Simulator 1.0 (WSNS) entnommen. Die Protokollewerden nach eigener Bezeichnung benannt, sofern sie eine besitzen, sonst im Rahmendieser Arbeit werden die Protokolle nach dem jeweiligen Projekt benannt, in dem sieimplementiert wurden. In der Tabelle 2.1 werden die Protokolle und die Projekte bzw.Betriebssysteme dargestellt.

TOS1 TOS2 Contiki WSNS SensorScopeRoute [29] Drip [34] uAODV [43] WSNS [13] SensorScope [12]

MintRoute [28] Dip [35] ContikiRPL [44]TinyAODV [27] Dhv [36]

DSDV [27] Ctp [41]Flood [27] Lqi [41]

MultihopLQI [31] Tymo [39]Drain [32] Blip [40]

ZigBee [42]

Tabelle 2.1.: untersuchte Routing Protokolle

Es ist zwar nicht Aufgabe dieser Arbeit, die Routingprotokolle ausführlich zu erklären,aber ein gewisses Verständnis über die Protokolle soll trotzdem gewonnen werden, umim Kapitel 3.2.3 die Protokolle plausibel kategorisieren zu können. Eine akkurate Kat-egorisierung macht die Untersuchung effektiver und gezielter. Im folgenden Abschnittwird eine kurze Einführung für jedes Protokoll gegeben. Es sollen dabei die Grund-prinzipien und Hauptdesignmerkmale jedes Protokolls gezeigt werden.

Einige Protokolle werden zusammen vorgestellt, aufgrund der Ähnlichkeit in angewandtenRoutingtechniken, Netzwerkarchitektur oder Verwendungszweck. Diese Zusammenhängewerden später bei der Kategorisierung der Protokolle berücksichtigt. Es wird daher er-wartet, dass ähnliche Funktionen oder Logik zwischen den zusammenhängenden Pro-tokollen zu finden sind.

9


Route und MintRoute

Route ist eine Implementierung für MultiHop Routing, MultiHop ist ein shortest-path-first-Algorithmus, d.h. die Route, die mit den wenigsten Hops2 zum Ziel (im MultiHopist dies die Basisstation) führt, bekommt die höchste Priorität. MultiHop verwendet dieLinkqualität3 zu den Nachbarmotes um den nächsten Hop zu bestimmen. Jedes Motefhrt eine Nachbartabelle (neighbor table) um die Linkqualittsentwicklung und Anord-nungsbeziehung zu den Nachbarmotes zu registrieren. Diese Tabelle wird aktualisiertwenn das Mote ein Routeupdate Paket bekommt.

MintRoute ist eine Weiterentwicklung des MultiHop-Routings. Der eigentliche Unter-schied zwischen MintRoute und MultiHop besteht darin, dass im Mintroute statt denHops die Linkqualität in Kombination mit einer zusammengesetzten Routequalität zuder Basisstation für die Routingentscheidung verwendet wird. Wenn ein Mote die gleicheLinkqualität zu zwei seiner Nachbarmotes hat, wird die Entscheidung willkürlich getrof-fen. Das kann auch zu Problem führen, dass die Route per Zufall in die Gegenrichtungzu der Basisstation führt.

TinyAODV

TinyAODV leitet sich vom Ad hoc On-demand Distance Vector (AODV4) Routing-protokoll aus dem MANET5 ab. TinyAODV behält dabei nur einen Teil von AODV’sFeatures um die Energie- und Ressourceneinschränkungen der Motes zu berücksichtigen.TinyAODV benutzt ein reaktives Routing, d.h. die Routingentscheidung wird erst getrof-fen, wenn eine Routinganfrage ankommt. Beim Bedarf von Routing wird das Sourcemoteeine Routinganfrage (RREQ) erzeugen und per Broadcast ins Netz schicken. Wenn dieRREQ die Zielstation oder eine Zwischenstation mit Routinginformation zur Zielstationerreicht, wird eine Routingantwort (RREP) auf dem gleichen Weg zurück zum Source-mote geschickt. Alle Motes, die sich in diesem Weg befinden, werden dabei mit einemRoutingeintrag zu dieser Zielstation bereichert.

2Hop bezeichnet in Rechnernetzen den Weg von einem Netzknoten zum nächsten. Die Hopanzahl istdie Anzahl an Schritten, die ein Paket auf dem Weg vom Absender zum Adressaten zurück legenmuss

3Diese Metrik beschreibt sowohl die Sendequalität als auch die Empfangsqualität. Die Berechnungdieser Metrik wird in [30] beschrieben

4C. E. Perkins et al., Ad hoc On-demand Distance Vector (AODV) Routing, IETF RFC 3561.5Mobile Ad hoc Networking Charter, http://www.ietf.org/html.charters/manet-charter.html.

10


DSDV

DSDV stellt eine many-to-one Routingmethode dar, wobei jedes Mal nur die Routezu einer gemeinsamen Zielstation gesucht wird, berücksichtigt mit Hopanzahl-Metrik,Quality-Metrik oder auch Energie-Metrik. Im DSDV schickt die Basisstation eine Nachrichtmit ihrem Identifier, einer Metrik und einer Sequenznummer periodisch ins Netzwerk.Alle Motes, die diese Nachricht empfangen haben, speichert den Identifier als das Zielfür den Routingalgorithmus und leiten die Nachricht anschlieend weiter. Diese Vorge-hensweise sorgt dafür, dass jedes Mal wenn eine solche Nachricht geschickt wird einneuer Baum aufgespannt wird.

Flood

Flood wurde implementiert um Datenpakete an alle Motes oder auch nur ein bestimmtesMote abzuliefern. Wenn ein Mote ein Datenpaket empfängt und stellt dabei fest, dassdieses Paket neu ist und die TTL6 größer 0 ist, wird das Paket an alle Nachbarmotes perBroadcast weitergeleitet. Wenn ein Paket für alle Motes bestimmt ist, wird das Eintre-ffen des Pakets bei allen Motes durch das intercept interface (entscheidet ob ein Paketweitergeleitet werden soll) signalisiert und anschließend per Empfanginterface empfän-gen. Wenn ein Paket nur für ein einziges Mote bestimmt ist, wird es zwar bei allen Motesebenfalls für den Abfang signalisiert, aber nur durch das Empfanginterface der Zielsta-tion empfangen. Jedes Mote soll dasselbe Paket von seinen unmittelbaren Nachbarmotesjeweils einmal empfangen, kann aber nur ein einziges Mal an seine Nachbarmotes weit-erleiten.

MultiHopLQI und Drain

Viele aktuelle Mote-Plattformen wie MicaZ oder Telos verwenden denselben Chip CC24207.Dieser Chip verfügt über einen Hardwareindikator und einen Link-Quality-Indikator(LQI). MultiHopLQI wurde entwickelt, um dieses Feature anzuwenden. Während imRoute und MintRoute die Linkqualität von den Einträgen in der Nachbartabelle vonden Nachbarmotes abhängt, berechnet MultiHopLQI diese durch Hardware. Jedes Mote

6Time To Live, http://de.wikipedia.org/wiki/Time_to_Live7CC2420 ist ein single-chip 2.4 GHz IEEE 802.15.4 RF-Transceiver designet für low-power- und low-

voltage-Wireless-Applikationen. http://docs.tinyos.net/index.php/CC2420

11


sendet per Broadcasting periodisch eine beacon-Nachricht, und die Empfänger dieserNachricht ziehen daraus einen LQI Wert mit Hilfe ihres Chips. Mit diesem Wert werdendann die Kosten für den Link berechnet. Die Kosten sind umgekehrt proportional zumLQI Wert. Der Link mit den niedrigsten Kosten wird dann für das Routing verwendet.

Das Drain-Collection-Protokoll ist eine Derivation vom MultiHopLQI und dient als dieBasis für die Dissemination Services [33] im TinyOS 2.x.

Drip, Dip und Dhv Drip, Dip und Dhv sind Ausbreitungsprotokolle (DisseminationProtocol) um neue Code an jedes Mote im Netzwerk zu verbreiten. Dhv ist ein Codekon-sistenzwartungsprotokoll, es sorgt dafür dass alle Motes im Netzwerk letztendlich dengleichen Code haben. Drip, Dip und Dhv basieren auf dem Trickle-Algorithmus8[37].

Drip benutzt keine Metainformation über die Daten und verbreitet sie unabhängigvoneinander und berücksichtigt nicht ob die Empfänger diese Daten bereits besitzen.Dip und Dhv verwenden dabei eine Identifizierung um nur ein bestimmtes Datensetzu verbreiten, also kollektiv. Drip verwendet die gesamte Dateninformation zum Abgle-ich der Daten, Dip generiert Hashwerte von der Information, aber beide verwenden diegesamte Dateninformation zum Abgleich. Dhv vergleicht hingegen z.B. beim Versions-abgleich nur bestimmte signifikante Bits um die zu übertragende Datenmenge nochmalzu reduzieren.

Ctp und Lqi mehr infor im datei CtpRoutingEngineP.nc

Ctp ist ein baumbasiertes Collection-Protokoll um die gesammelten Daten von Motes indie Rootknoten zu befördern. Einige Motes dienen als Rootknoten, die anderen Motesspannen eine Gruppe von Routingbäumen für die Rootknoten auf. Ein Mote wählt seinenRootknoten nicht explizit, sondern benutzt einen Gradienten der expected transmissions(ETX), um die Route zum Rootknoten zu generieren. Ein Rootknoten hat den ETX 0,ein Mote hat den ETX von seinem Vaterknoten plus den ETX von dem Link zwischendem Mote und dem Vaterknoten. Ctp wählt die Route mit dem kleinsten ETX.

Lqi ist ein anderes Collection-Protokoll. Seine Softwarestruktur ist ähnlich mit Ctp,es wird aber durch einem separaten Link-Kalkulator erweitert.

8Trickle ist ein selbstregulierender Algorithmus für Codeverbreitung und -Wartung in WSN

12


Tymo

Tymo ist eine Implementierung des DYMO-Protokolls [38] im TinyOS. DYMO ist einpoint-to-point-Routingprotokoll für MANET. Es wurde entwickelt um die Route auf demIP-Stack dynamisch zu finden. Tymo passt dieses Protokoll für TinyOS an, indem es denIP-Stack auf den Active-Message-Stack vom TinyOS umsetzt.

Als reaktives Protokoll berechnet DYMO eine Unicast-Route bei Bedarf. Wenn ein Moteeine Route braucht, verbreitet er eine RREQ. Diese Anfrage wird dann flutartig ins ganzeNetzwerk oder auch nur innerhalb einer Distanz von bestimmter Hopanzahl gesendet.Wenn das Ziel oder eine Zwischenstation mit aktueller Routeinformation zum Ziel er-reicht ist, wird eine RREP zurückgeschickt. Wenn ein Mote eine RREQ oder RREPempfängt, cacht es die Routeinformation für den späteren Routingbedarf. Dieses Rout-ingverfahren ist ähnlich dem TinyAODV.

Blip

Blip, der Berkeley-Low-Power-IP-Stack, ist eine Implementierung einiger IP-basierterProtokolle wie TCP und UDP. Damit öffnen sich die Möglichkeiten die vielen bereitsin IP-Netzwerken etablierte Features wie Lookup, NAT in WSN einzusetzen. Blip bautauf 6LoWPAN9 und IEEE 802.15.410 auf. Alle Motes in einem Blip-Netzwerk dienenals Router und bilden damit ein MultiHop-IP-Netzwerk. Es gibt in einem Blip-Netzwerkauch Subnetzwerke, die aus mehreren Motes bestehen. Einer oder mehrere von den Moteskann über zusätzliche Funktionen verfügen und dient als edge routers, welches Daten-pakete zwischen den Netzwerken routet.

ZigBee

ZigBee NWK ist eine Implementierung vom ZigBee Network Layer mit Unterstützung

9Der Standard umfasst ein Header-Kompressionsverfahren, welches es effizienter macht IPv6-Paketeüber IEEE 802.15.4-basierende Netzwerke zu übermitteln

10Der Standard IEEE 802.15.4 beschreibt ein Übertragungsprotokoll für Wireless Personal Area Net-works (WPAN). Er definiert die untersten beiden Schichten des OSI-Modells, den Bitübertragungs-und den MAC-Layer.

13


für Cluster trees11. Der Routingalgorithmus basiert auf dem Adressmodell des Netzwerks.Wenn ein Mote einen Dataframe empfängt, wird der Algorithmus das Routinginforma-tionsfeld auslesen und die Zieladresse überprüfen. Wenn die Zieladresse und die eigeneAdresse gleich sind, werden die Nutzdaten an die höheren Layer weitergegeben. Wenndie Adressen ungleich sind, also die Daten nicht für dieses Mote bestimmt sind, mussdas Mote den nächsten Hop berechnen. Wenn das Mote ein ZigBee Koordinator ist,überprüft das Mote anhand seiner Nachbartabelle ob das Ziel ein Kindknoten von ihmist und gegebenenfalls das nächste Hop mit der kleinsten Adresse wählen. Ansonstenmuss das nächste Hop per Cluster-Tree-Routing berechnet werden.

uAODV

Das ursprüngliche AODV-Protokoll (RFC 3561) wurde entwickelt für Geräte wie Lap-tops, mit hochkapazitätigen Akkus und mehr Arbeitsspeicher. Somit können „gesprchige“ Pro-tokolle verwendet werden, um die Netzwerkstruktur zu erkunden12 und ständig neueRouten berechnen und größere Mengen von Informationen über das Netzwerk im Spe-icher zwischengespeichert werden. Um AODV in eingebetteten Systeme zu verwendenund trotzdem die Einschränkungen an Energie und Ressourcen zu berücksichtigen wurdeuAODV entwickelt.

uAODV verwendet die Statistik über Retransmission13 um die Verfügbarkeit eines Hopszu ermitteln. Für jede erfolgreiche Paketlieferung per Unicast wird die Anzahl von Re-transmissionen registriert. Daraus wird ein Laufzeitdurchschnitt der Retransmissionenberechnet. Wenn ein Hop mehr Retransmissionen als diesen Durchschnitt hat, wird dasHop als nicht verfügbar angesehen. Im uAODV wird eine Route länger als einen Monatfestgehalten. Wenn eine Route gebrochen14 ist, wird die Route mit einer RERR Nachrichtvon der Bruchstelle rückwärts bis zu Source abgebaut.

ContikiRPL

11In einem Baumnetzwerk gibt es ein globaler Koordinator, dessen Knoten wiederum lokale Koordinatorsind

12Durch häufgies Broatcast von HELLO-Nachrichten kann beispielsweise die Verfügbarkeit der Nach-barknoten zu erkundet werden.

13Der IEEE 802.15.4 Netwerk-Standard hat einen Mechanismus für Paket-Acknowledgments auf demLink-Level.

14Z.B. durch ein ausgefallenes Mote oder was auch immer das Hop ungültig macht, ein badhop

14


Das ContikiRPL Protokoll ist das Standard-IPv6/6lowpan-Routingprotokoll im Conti-ki, es ist eine Implementierung für RPL. RPL verwendet den Distanzvektoralgorithmusfür dynamisches Routing in IPv6-Netzwerken mit low-power-Geräten und lossy (verlust-behafteten) Links. Hierbei wird angenommen, dass der meiste Datenverkehr in einemMuster von many-to-one oder one-to-many fliet. Um diesem Muster zu entsprechenunterhält RPL einige auf Rootknoten gerichtete azyklische Graphen (DAGs), die an-hand einer Zielfunktion15 (spezifiziert durch Einschränkungen und Metrik im Netzwerk)generiert werden. Das Hauptziel des Designs vom ContikiRPL ist ein vielfältiges abergleichzeitig einfaches Programmierungsinterface anzubieten, das zur Untersuchung derobjektiven Funktion verwendet werden kann.

WSNS

Der Routingalgorithmus von WSNS ist eine erweiterte Version vom LEACH[45] Rout-ingprotokoll. LEACH, Low Energy Adaptive Clustering Hierarchy, ist ein hierarchischesclusterbasiertes Routingprotokoll. LEACH wählt willkürlich ein Paar Motes als Clus-terheads aus. Die Motes übernehmen diese Rolle abwechselnd um ein gleichmäßige En-ergieniveau der Motes zu erhalten. Der Clusterhead komprimiert die Daten, die vonden Motes aus seinem Cluster kommen, bevor sie an die Basisstation weiter übertragenwerden, damit reduziert sich die zu übertragende Datenmenge und damit verbundeneBandbreite und Energie. Die Einsammlung von Daten erfolgt im LEACH periodisch; dasist ein Nachteil des Protokolls, denn manchmal ist eine periodische Einsammlung nichtnötig und verbraucht zu viel Energie. Der Algorithmus im WSNS soll für eine höhereLebensdauer des Netzwerks und der Motes sorgen.

SensorScope

SensorScope ist ein auf WSN basiertes Messsystem mit Anforderungen wie niedrigem En-ergieverbrauch, großem Kommunikationsradius, geringen Kosten, einfacher Installationund Datenabfrage in Realzeit. Dafür wurde ein spezieller energieeffizienter Multi-HopRouting Stack entwickelt. Ein Routing Stack soll SensorScope die Datenübermittlungüber großen Distanzen, flexible Netzwerktopologie und automatische Routeänderungbeim Ausfall eines Messknotens ermöglichen. Neben Dateneinsammlung und Routingsoll der Stack noch der Zeitsynchronisation dienen um ein Zeitstempel von der Basissta-

15Eine Funktion für Optimierungsprobleme, entscheidet wie gut eine Lösung ist.

15


tion in alle Motes zu verbreiten.

Als die Plattform für diesen Routing-Stack wurden zwei MultiHop-Routingprotokolle,Route und MintRoute, aus TinyOS entnommen. Die signifikante Änderung in der Im-plementierung vom SensorScope ist ein zusätzliches Multi-Hop-Hybrid ARQ (NHARQ)[46] Layer zwischen dem Netzwerk- und dem Linklayer.

16

2.2 Klone und Klonerkennung

2.2. Klone und Klonerkennung

Dieses Unterkapital gibt eine Einführung in die Thematiken Klone und Erkennungs-Techniken. Nach einer Definition und der Erklärung der gebräuchlichen Begrifflichkeitenwird ein kurzer Überblick über die verschiedenen Erkennungs-Techniken gegeben, dasAugenmerk liegt dabei auf einem Vergleich der verschiedenen Ansätze und deren Eigen-schaften, und in den daraus resultierenden Auswahlkriterien für die Testwerkzeuge, diein diesem Projekt verwendet werden. Ein ausführlicher Vergleich der Techniken findetsich in [1].

2.2.1. Code-Klone

Code-Klone sind Codefragmente (CF) im Quellcode, die identisch oder ähnlich mit einan-der sind. Häufigster Grund für Code-Klone ist die Wiederverwendung bereits existierendeFunktionalitäten durch einfaches Copy&Paste. Um zum Beispiel die vorhandene Funk-tionalität an einer anderen Stelle in gleicher oder ähnlicher Weise wiederverwenden zukönnen, wird Code an die betreffende Stelle kopiert. Der kopierte Code kann dabei mitAnpassung auf den jeweiligen Kontext, Erweiterungen oder Modifikationen versehenwerden.

Die Gründe für Copy&Paste sind beispielsweise der Aufwand der Modularisierung, oderdie begrenzten Ressourcen eines eingebetteten Systems, welche nicht durch extra Funk-tionsaufruf weiter belastet werden sollen. Dennoch ist Code-Klone eine bad practice [3].

Ein Codefragment kann unterschiedlichste Granularität haben. D. h. ein Codefragmentkann eine ganze Funktionsdefinition, eine Reihe von Funktionsdefinitionen oder ebennur eine Sequenz von beliebigen Statements sein. Ein Codefragment wird durch einenn-Tupel gekennzeichnet, (CF-Dateiname, CF-Anfangszeile, CF-Endzeile).

2.2.1.1. Klonpaar

Wenn zwei Codefragmente für eine gegebene Definition von Ähnlichkeit f() (siehe 2.2.1.3)nach ähnlich sind, also f(CF1) = f(CF2), werden sie als ein Klon-Paar (KP )(CF1, CF2)

17


bezeichnet. Die Ähnlichkeit ist symmetrisch und reflexiv, aber nicht zwangsläufig tran-sitiv. Existieren Klonpaare KP1(CF1, CF2) und KP2(CF2, CF3), so existiert nichtzwangsläufig auch das Klonpaar KP3(CF1, CF3).

2.2.1.2. Klonklasse

Eine Klon-Klasse beschreibt mehrere Codefragmente der gleichen oder ähnlicher Funk-tionalität. Es handelt sich um eine Äquivalenzklasse bezüglich der zwischen all diesenKlonfragmenten gemeinsamen Klonpaar-Relation. Das bedeutet insbesondere aufgrundder Transitivität der Relation, dass jedes Fragment einer Klasse zu jedem anderen Frag-ment dieser Klasse ein Klon ist.

2.2.1.3. Klontypen

Es gibt zwei Sorten von Ähnlichkeit zwischen den Codefragmenten. Erstens könnendie Codefragmente ähnlichen Programmtext haben, unabhängig von der Bedeutung.Zweitens können die Codefragmente ähnliche Funktionalität haben, unabhängig vomProgrammtext. Abhängig von der Art der Ähnlichkeit der jeweiligen Codefragmentewerden Code-Klone in vier Typen unterschieden:

Typ 1: exakte Kopie

Ein Typ 1-Klon ist eine 1:1-Kopie des Originals bis auf Unterscheidung im Layout(Leerzeilen,Tabulator u.s.w.) oder Kommentaren.

int sum( int a ){int sum=0;for ( int i =0; i<a ; i ++){

sum = sum + i ;}return sum ;

}

int sum( int a ){ // Ein Kommentarint sum=0;for ( int i =0; i<a ; i ++){


}

Abbildung 2.5.: Beispiel für einen Typ 1-Klon

18


Typ 2: Kopie mit parametrisierter Übereinstimmung

Bei einem Typ 2-Klon, werden neben Änderungen im Layout oder Kommentaren, auchnoch die Bezeichner von Funktionen oder auch Variablen umbenannt. Weitergehendkönnen Typ 2-Klone noch in Klone mit konsistenter und inkonsistenter Umbenennungunterteilt werden. In einem konsistent umbenannten Codefragment werden ein Bezeich-ner und alle weiteren Vorkommen dieses Bezeichners auf die gleiche Weise umbenannt,wodurch eine Gleichheit in der Semantik der betroffenen Codefragmente gegeben ist.Hingegen ist dies in einem Klon mit inkonsistenter Umbenennung nicht zwangsläufigder Fall.

int sum( int a ){int sum=0;for ( int i =0; i <a ; i ++){


}

KonsistenteUmbenennung

int sum( int a ){int s =0;for ( int i =0; i<a ; i ++){

s = s + i ;}return s ;

}

original

int summe( int a ){int sum=0;int b=0;for ( int i =0; i<a ; i ++){

sum = b + i ;}

}

InkonsistenteUmbenennung

Abbildung 2.6.: Beispiel für Typ 2-Klon

Typ 3: Kopie mit weitergehenden Modifikationen

Ein Typ 3-Klon entsteht häufig, wenn eine ähnliche Funktionalität benötigt wurde, undleichte Änderungen an einer Kopie vorgenommen wurden. Es handelt sich meist umeinen Typ 1- oder Typ 2-Klon, der durch beispielsweise Hinzufügen oder Löschen einzel-ner Anweisungen modifiziert und somit unterbrochen wurde. Einige Verfahren nutzendiese Eigenschaft und erkennen dann Typ 3-Klone als zusammengesetzte Typ 1- oderTyp 2-Klone, getrennt durch ungleiche oder unähnliche Anweisungszeilen.

Typ 4: semantisch ähnliche Kopie

Diese Art von Klon besteht aus Codefragmenten, die zwar die gleiche Funktionalitätdecken, die gleiche Semantik, aber syntaktisch unterschiedlich formuliert wurden. So lsst

19




}

int summe( int a ){int sum=0;for ( int i =0; i<a ; i ++){

sum = sum + i ;c o u n t s t e p ( ) ;

}return sum ;

}


sich eine for-Schleife in eine while-Schleife umschreiben, oder der Inkrement-Operator++ lässt sich ausschreiben.



}

int summe( int a ){int counter =0;int sum=0;int i =0;while ( i<a ){

sum = sum + i ;counter++;

}return sum ;

}


2.2.2. Klonerkennungsprozess

Klonerkennung ist ein zweiphasiger Prozess. Er besteht aus einer Transformationsphaseund einer Vergleichsphase. In der Transformationsphase wird der Quellcode in ein in-ternes Format transformiert. Der transformierte Quellcode kann dann in der Vergle-ichsphase mit bestimmten Vergleichsalgorithmen effizient verglichen werden, wobei dieDuplikate im Quellcode erkannt werden.

2.2.3. Klonerkennungsverfahren

Die Transformation des Quellcodes stellt eine Abstraktion des Quellcodes dar. Die In-formationen über den Quellcode, die beim Vergleich verwendet werden, können in un-terschiedlichen Formen und Stufen abstrahiert werden. Viele Methoden und Technikenzur Klonerkennung wurden bereits in der Literatur vorgestellt. Sie unterscheiden sich in

20


der Form oder der Stufe der Abstraktion, die zur Analyse des Codes verwendet werden.

In diesem Abschnitt werden verschiedene Verfahren zur Klonerkennung betrachtet. Esgibt noch viele Erweiterungen von den jeweiligen Verfahren, oder viele neue Verfahren,die auf den gleichen Grundprinzipien beruhen. Daher wird hier für einige Verfahren nurder Pionier vorgestellt, womit effiziente Klonerkennung realisiert wurde. Neben einerkurzen Erläuterung der Verfahren werden dabei vor allem einige Merkmale und darausresultierende Einschränkungen, sowie weitere Vor- und Nachteile genauer betrachtet.

Nach der Abstraktionsstufe der zu vergleichenden Einheiten können die Verfahren grobin 5 Kategorien unterteilt werden.

2.2.3.1. Textbasierte Verfahren

Das textbasierte (auch bekannt als string-basiert) Verfahren verwendet einfache String-Transformation und -Vergleichsalgorithmen. Das macht dieses Verfahren unabhängigvon der Programmiersprache des zu vergleichenden Quellcodes.

Einfacher Zeilenabgleich

Für einen einfachen Zeilenabgleich werden nur wenige oder gar keine Transformatio-nen am zu vergleichenden Quellcode angewandt. Es beschränkt sich üblicherweise aufEntfernung von Leerzeilen, Leerstellen und Kommentare. Dabei sind sehr wenig odergar keine Kenntnisse über die Programmiersprache des Quellcodes erforderlich.

Während der Vergleichsphase werden alle Codezeile anhand eines Zeilenabgleichsalgo-rithmus miteinander verglichen. Das verursacht einen großen Suchraum. Um diesen zureduzieren, werden die Hashwerte jeder einzelnen Codezeile vor dem Vergleich in diversenHashbehältern gespeichert, und dann innerhalb jedes Hashbehälters die Hashwerte ver-glichen. Ein Vertreter dieses Verfahrens ist das Tool Duploc [5] von Ducasse.

Parametrisierter Zeilenabgleich

Während mit einfachem Zeile-Abgleich nur identische Codefragmente erkannt werden

21


können, knnen mit parametrisiertem Zeilenabgleich auch ähnliche Codefragmente erkan-nt werden. Die Idee dahinter ist, dass die Namen von Bezeichnern und Literalen währenddes Copy&Paste verändert werden können, und als Parameter betrachtet werden kön-nen. Somit können die Codefragmente, die sich nur in Bezeichnernamen unterscheiden,auch berücksichtigt werden.

Die Parametrisierung kann erfolgen, indem während der Transformation des Quellcodesalle Bezeichner und Literale mit einem gemeinsamen Symbol wie ‚$ ‘ersetzt werden.Dadurch ist der Vergleichsprozess unabhängig von den Parametern, und der Vergleich-salgorithmus selbst muss nicht modifiziert werden.

Insgesamt, kann das textbasierte Verfahren Klonpaare des Typs 1 erkennen, mit Hilfedes parametrisierten Zeilenabgleichs auch Klonpaare des Typs 2 bei konsistenter Umbe-nennung. Da die syntaktischen Grenzen nicht berücksichtigt werden, ergibt sich dadurchhohe Rate von False-Positiven.

2.2.3.2. Tokenbasierte Verfahren

Brenda S. Baker hat erstmals ein Verfahren vorgestellt [6], bei dem ein tokenbasiertesPattern-Matching verwendet wurde.

Für jede Zeile des Quellcodes wird zunächst ein Parameter-String (P-String) generiert,in dem die Bezeichner und Literale in Parametersymbole transformiert werden, und dietypographische Struktur mit Nichtparametersymbole codiert wird. Das Ergebnis ist einkonkatenierter P-String aller P-Strings, der den gesamten Programmcode repräsentiert.Der P-String wird anschließend in einen P-Suffix-Baum übertragen. Aus diesem lassensich nun die Position, sowie Länge und Anzahl der Klone direkt bestimmen.

Durch Anwenden einer Funktion prev() auf den P-String vor dem Aufbau des Suffix-Baums kann von Bezeichnern abstrahiert und somit Klonpaare vom Typ 2 mit kon-sistenter Umbenennung erkannt werden. Die Funktion ersetzt dabei jeden Bezeichnerdurch die relative Position seiner letzten Verwendung.

Dieses Verfahren liefert Klonpaare vom Typ 1 und Typ 2 mit konsistenter Umbenen-

22


nung. Klonpaare von Typ 3 können erkannt werden, indem zwei oder mehrere nichtdirekt hintereinander folgende Klonpaare von Typ 1 oder Typ 2 konkateniert werden,wobei der lexikalische Abstand dazwischen einen vom User vordefinierten Schwellenwert(ein Gap16) nicht überschreiten darf. Durch eine niedrige Abstraktionsstufe ist diesesVerfahren weitgehend programmiersprachenunabhängig. Da wie beim textbasierten Ver-fahren die syntaktischen Grenzen nicht berücksichtigt werden, ergibt sich ebenfalls einehohe Rate an Flase-Positiven.

2.2.3.3. Baumbasierte Verfahren

Bei baumbasierten Verfahren werden die Quellcodes auf der syntaktischen Ebene unter-sucht. Dazu werden aus dem Quellcode mittels Parser parse trees oder abstract syntaxtrees (ASTs) gebildet, welche dann auf gleiche oder ähnliche Teilbäume untersucht wer-den.

Dieses Verfahren wurde von Ira D. Baxter u.a. entwickelt und in dem Tool CloneDR[9] implementiert. Es wird zunächst der AST des zu untersuchenden Quellcode erstelltund dabei alle Teilbäume ihrer Art (der Anweisung im jeweiligen Wurzel-Knoten) nachauf verschiedene Hashbehälter verteilt, um einen quadratischen Aufwand der Vergleichealler Teilbäume zu vermeiden.

Dann werden alle Teilbäume innerhalb eines Behälters mit Hilfe einer Ähnlichkeits-funktion auf Gleichheit, bzw. Ähnlichkeit überprüft. Um im Ergebnis nur „maximaleKlone“ zu erhalten, werden dabei eventuell bereits vorhandene Klone zwischen Teil-bäumen wieder entfernt. Zur Erkennung von Klonen, die aus mehreren Anweisungenbestehen, ist es außerdem nötig, in einem weiteren Schritt „Sequenzen von Klonen“ zueinem zusammenzufassen und dann ggf. deren „Vater-Knoten“ erneut zu prüfen.

Abhängig von der gewählten Ähnlichkeitsfunktion erkennt das Verfahren Klonpaareder Typen 1, 2 und 3 17. Eine Besonderheit des Verfahren ist, dass auch die Kommu-

16Während Copy&Paste können zusätzliche Statements in den originalen Code hinzugefügt werden.Dieser Teil von zusätzlichem Code wird als Gap bezeichnet, und solche Klone werden auch „gappedclone“ genannt

17Die Typ 3-Erkennung erfolgt dabei in einem separaten Schritt am Ende, ähnlich wie beim token-basierten Verfahren

23


tativität von Operatoren berücksichtigt werden kann. Auf Grund des syntaxbasiertenAST-Abgleichs ist das Verfahren relativ aufwändig. Da für die Erstellung des ASTs einParser für die jeweilige Programmiersprache notwendig ist, ist das Verfahren zudemwenig programmiersprachenunabhängig. Um die Komplexität eines vollständigen Teil-bäumevergleich zu vermeiden, wurden in neueren Verfahren alternative Baumdarstellun-gen verwendet. In dem Verfahren von Koschke u.a. [20] werden die AST-Teilbäume ineine AST-Nodesequenz serialisiert, für welche wiederum ein Suffix-Baum gebildet wird.Damit können die syntaktischen Klone mit der Geschwindigkeit von tokenbasierten Tech-niken gefunden werden.

2.2.3.4. Metrikbasierte Verfahren

Metrikbasierte Verfahren beruhen auf die Idee, den Quellcode anhand einer Menge vonSoftware-Kennzahlen (Software-Metrik) zu charakterisieren. Diese Kennzahlen könnendie Identifikationsmaßstäbe für die funktionelle Struktur sein, manchmal aber auch fürdas Layout.

Eine populäre Technik an die Kennzahlen zu gelangen ist die Generierung eines Metrik-Fingerabdrucks. Der Quellcode wird dabei meistens zunächst in einen AST oder einenKontrollflussgraphen geparst. Der AST wird dann in interessante Fragmente aufgeteilt.Die Entscheidung darber, welche Fragmente interessant sind, ist wichtig, denn diese kanndas Ergebnis stark beeinflussen. Üblicherweise werden dafür syntaktische Einheiten wieKlasse, Funktion und Methode ausgewählt, denn diese lassen sich leicht aus dem AST ab-strahieren. Nachfolgend werden eine Menge von vordefinierter Metrik für die Fragmenteberechnet. Die Metrik kann in der praktischen Implementationen des Verfahrens ver-schieden sein, aber meistens spezifizieren sie die funktionellen Eingenschaften. Trotzdemgibt es auch Implementationen, in denen eine Layout-Metrik wie die McCabe-Metrik(zyklomatische Komplexität), Function-Points oder lines-of-code (LOC) verwendet wer-den. Zum Schluss werden die Sets von Metrik, also die Fingerabdrücke miteinanderverglichen. Abhängig von der tatsächlichen Implementation werden dabei verschiedeneAlgorithmen verwendet, z.B. durch Berechnung von der euklidischen Distanz eines Fin-gerabdruckpaars, wobei Null auf ein Klonpaar hindeutet.

Da auf der Funktionsebene die meisten Metriken existieren, werden üblicherweise Klon-

24


paare von Funktionen der Typen 1, 2 und 3 erkannt. Aber eine kleine Funktion, die z.B.durch manuelles In-Lining in zwei größeren Funktionen hinzugefügt wird, kann dabeinicht erkannt werden, da die großen Funktionen sehr verschieden sein können. Durch dieAnnährung mit den Metrik kann es übrigens viele False-Positive geben, da zwei ganzunterschiedliche Codefragmente trotzdem ähnliche Metrik aufweisen knnen.

2.2.3.5. Graphenbasierte Verfahren

Die graphenbasierte Techniken gehen noch einen Schritt über die syntaktische Ebenehinaus, betrachten den Quellcode in einer höhere Abstraktionsebene mittels statischeAnalyse des Quellcodes.

In einigen Verfahren wird der Quellcode in einem program dependency graph (PDG)dargestellt. Die Knoten dieses PDG repräsentieren Ausdrücke und Statements, whrendKanten den Kontroll- und Daten-Fluss eines Programms bezeichnen. Mit dieser Repräsen-tation werden die semantischen Abhängigkeiten der Ausdrücke und Statements aus demlexikalischen Ablauf abstrahiert. Die Suche nach Code-Klonen wird nun zu einer Suchenach isomorphen Teilgraphen.

Aufgrund der hohen Abstraktionsstufe des Quellcodes können theoretisch alle Typenvon Code-Klonen mit diesem Verfahren erkannt werden. Leider es gibt noch keine aus-reichend effektive Implementation davon.

2.2.4. Ausgewählte Klondetektoren

Durch manuelle Beobachtung des Codes der Protokolle, lassen sich die Arten potenziellerKlone des Typs 2 mit konsistenter Umbenennung und Typ 3 schätzen. Für die Unter-suchung der Routingprotokolle werden drei Klondetektoren ausgewählt, CCFinder [8],Ccdiml [21] und Deckard [10]. CCFinder fällt in die Kategorie tokenbasierte Verfahren.Ccdiml und Deckard fallen in die Kategorie Baumbasierte Verfahren. Aber mit ihrenzahlreichen Erweiterungen und neuartigen Ansätzen sind die Tools mehr oder wenigerHybridverfahren und vereinen damit Vorteile aus mehreren in 2.2.3 vorgestellten Ver-

25


fahren. Das macht die Tools besonders interessant und mächtig18. In diesem Abschnittwerden die Detektoren vorgestellt, hinsichtlich verwendetem Verfahren, den Besonder-heiten und den Erweiterungen. Näher werden die Funktionsweise der Detektoren imKapital 3.2.2 im Zusammenhang mit der Parameterbestimmung erläutert.

2.2.4.1. CCFinder

CCFinder ist ein für die Analyse von großen Softwaresystemen konzipiertes Klonerken-nungstool und kann den tokenbasierten Verfahren zugeordnet werden. CCFinder ver-wendet zur Klonerkennung einen Suffixbaumabgleichalgorithmus. Drüber hinaus bietetCCFinder noch einige sinnvolle Optimierungstechniken.

Bevor der Quellcode in einen Tokenstring trasformiert wird, wird eine programmier-sprachespezifische Normalisierungsregel darauf angewandt. Dadurch kann das Abstrak-tionsniveau des Tokenstrings erhöht werden und ein effektiverer Abgleich realisiert wer-den. Im CCFinder sind bereits Regeln für C, C++, C#, VB, Java und COBOL imple-mentiert.

CCFinder hat ein „Shaper“für Code-Klone implementiert, welches sinnvolle19 Teilcodesaus einem Klon ausgibt. Dabei werden die syntaktische Informationen wie Funktion-srumpf und Loop, die während der Transformation gewonnen wurden, verwendet.

CCFinder bietet noch einige Metriken bezüglich Code-Klone wie Klonlänge, Klonpopu-lation und Klonverteilung, die für die Auswertung der Klonpaare und Klonklassen sehrnützlich sind. Außerdem stellt die graphische Version von CCFinder, CCFinderX, nochein Steuerdiagramm zur Darstellung der Klonverteilung dar. In Kombination mit derGeschwindigkeit der tokenbasierten Verfahren, eignet sich CCFinderX daher sehr gutdafür, ohne tiefere Kenntnisse über den zu testende Quellcode gleich am Anfang einengroben Überblick über die Klonverteilung zu gewinnen.

18Es gibt nach [1] noch einige andere interessanten Klondetektoren, die noch besseres Performancehaben sollen, jedoch waren sie zum Zeitpunkt dieser Arbeit nicht verfügbar.

19Mit sinnvoll ist hier gemeint, dass dieser Teil des Codes eine abgeschlossene Struktur hat und sichdadurch besser für Merging eignet.

26


2.2.4.2. Ccdiml

Ccdiml (Code Clone Detection on IML) ist im Programmset Bauhaus Suite [21] en-thaltenes Klonerkennungstool. Ccdiml ist die Implementation einer Variation von Bax-ters syntaxbasiertem Verfahren und fällt daher in die Kategorie der baumbasierten Ver-fahren. Im Gegensatz zu gewöhnlichen baumbasiertem Verfahren, nutzt Ccdiml einenabstrakten Syntaxbaum im IML-Format (InterMediate Language [22]) 20.

Das Bauhaus Suite erzeugt21 aus dem jeweiligen Quellcode des zu analysierenden Sys-tems einen Zwischencode – die Intermediate Language (IML). Es handelt sich hierbeium eine weitgehend programmiersprachenunabhängige Darstellung. Damit wird die In-tegration weiterer Analysen erheblich vereinfacht und es besteht eine hohe Wiederver-wendbarkeit bereits vorhandener Analysen. Zudem wird durch hohe Abstraktion beigleichzeitiger größtmöglicher Quellnähe ein weitreichendes Spektrum möglicher Anal-ysen abgedeckt. Die IML stellt im Wesentlichen eine spezielle Form eines abstraktenSyntaxbaums, angereichert mit Kontrollfluss- und Datenfluss-Informationen, dar.

Ccdiml bietet zahlreiche Möglichkeiten an, den gesamten Klonerkennungsprozess zu bee-influssen und zu optimieren. Es gibt dafür diverse Filter wie Zeilenlänge (pre_minlines),Teilbaumtiefe (pre_mindepth) und Teilbaumgewichtung (pre_minweight). Für die Erken-nung von Typ-3-Klonen gibt es noch den Parameter type3gap, welcher die maximaleGaplänge definiert. Darüber hinaus klassifiziert Ccdiml die gefundenen Klonpaare nachKlontypen.

2.2.4.3. Deckard

Deckard von Jian u.a. [10] fällt in die Kategorie der baumbasierten Verfahren. Das Toolberechnet zunächst die charakteristischen Vektoren für die Teilbäume im euklidischenRaum, um die strukturellen Informationen des ASTs zu approximieren, und dann wer-den die ähnlichen Vektoren anhand der euklidischen Distanz22 der Vektoren gruppiert.20vergleichbar mit der Objektdatei, einem Maschinencode, der Referenzen auf die Laufzeitbibliothek

und externe Bibliotheken beinhaltet. Die Referenzen werden später mit Linkern aufgelöst.21Bauhaus verwendet dabei eigene Compiler cafe und Linker imllink [22], unterstützt werden die Pro-

grammiersprachen C und C++22Da es sich um eine Metrik handelt, kann Deckard auch als metrikbasiertes Verfahren klassifiziert

werden.

27


Anschließend wird unter der Verwendung von Locality sensitive hashing (LSH) [23][10]in jeder Gruppe nach Klonen gesucht.

Der charakteristische Vektor eines Teilbaums ist ein Punkt < c1, ..., cn > im euklidis-chen Raum, wobei jedes Token ci die Auftrittshäufigkeit eines spezifischen Baummustersrepräsentiert. Da nicht jeder Knoten im AST relevant ist um die strukturelle Informationdes Baums zu wiedergeben, hat Deckard die Knoten in relevante Knoten und irrelevanteKnoten unterteilt. Zu den irrelevanten Knoten gehören z.B. ‚[‘ und ‚]‘, ‚(‘ und ‚)‘. Zuden relevanten Knoten gehören z.B. ID, Literal, Assignment, Inkremment und Kondi-tion. Nur die relevanten Knoten werden zur Bildung der Vektoren verwendet.

Die minimale Größe des zu betrachten Teilbaums kann durch die Quersumme aller To-ken in einem Vektor (minimale Tokenanzahl) bestimmt werden, damit können zu kleineTeilbäume bzw. zu kleine Klone vermieden werden.

Gängige baumbasierte Verfahren berücksichtigen nur die Codefragmente, die einen Teil-baum darstellen. Aber manchmal fügt Entwickler auch ein Codefragment in größereKontexte hinzu. Da die Codeumgebung, die die hinzugefügte Codefragmente einschließtdoch sehr verschieden sein können, können die hinzugefügten Codefragmente nicht ef-fektiv als Klon erkannt werden. Um die Codefragmente trotzdem entdecken zu können,wird im Deckard eine zweite Phase namens vector merging in die Vektorgenerierungeingefügt. In diesem Schritt wird der AST durch die Vektoren bestimmter Knoten 23

in serialisierter Form dargestellt und ein Schiebefenster über diese serialisierte Formgeschoben. Dabei werden die Vektoren in dem Fenster zu einem merged vector zusam-mengefasst. Die Größe des Schiebefensters ist von 2 bis inf (entspricht keinem Merging)frei wählbar. Ein großes Schiebfenster erhöht zwar die Anzahl und Größe der entdecktenKlone, erhöht aber den Zeitaufwand drastisch [24], besonders in Zusammenhang miteinem kleinen Schwellenwert für die Ähnlichkeit (Similarity).

Durch die Annäherung des AST, das nummerische Vergleichverfahren und das vectormerging ist Deckard in der Lage Code-Klone von Typ 1, 2 und 3 zu erkennen und dabeischneller als traditionelle Teilbauvergleich [24] und robuster gegenber Codemodifikatio-nen.

23Die Auswahl der Knoten sind essentiell. Details darüber findet man in [?]

28

3. Beschreibung des Tests

In diesem Kapital wird zuerst der Testaufbau beschrieben, indem Testgegenstand, Test-werkzeug und Testumgebung vorgestellt werden. Danach werden die für diese Arbeitnotwendigen Vorbereitungen und die tatsächliche Umsetzung beschrieben.

3.1. Teststruktur

In diesem Projekt sollen 19 ausgesuchte Routing-Protokolle mit Hilfe von Klonerken-nungstechniken und -tools auf duplizierte oder ähnliche Funktionen untersucht werden.Das Augenmerk wurde hierbei auf Codefragmente gerichtet, die sich später eventuellvom Entwickler leichter modularisieren lassen, z.B. in sich abgeschlossene funktionelleCodeblöcke wie eine Funktionsdefinition oder eine längere Sequenz von Statements, dieeinen komplexen Verarbeitungsschritt oder eine Logik im Ablauf einer Funktion

Code-Klone innerhalb eines Protokolls werden in der Analyse der Ergebnissen nichtberücksichtigt, es sei denn sie gehören zu einer protokollübergreifenden Klonklasse.

3.1.1. Testgegenstand

Der Testgegenstand dieser Arbeit sind 19 Routingprotokolle aus TinyOS 1.x, TinyOS2.x, Contiki 2.x, SensorScope und WSN Simulator 1.0. Die Protokolle wurden bereitsim Kapital 2.1.2.1 ausführlicher beschrieben.

29

3.1 Teststruktur

. . .

module DhvVersionP {p r o v i d e s i n t e r f a c e DhvHelp ;p r o v i d e s i n t e r f a c e DisseminationUpdate<dhv_data_t >[dhv_key_t key ] ;p r o v i d e s i n t e r f a c e DhvCache as DhvDataCache ;p r o v i d e s i n t e r f a c e DhvCache as DhvVectorCache ;

}

implementation {

. . .

command uint8_t DhvDataCache . nextItem ( ) {dhv_index_t i ;for ( i = 0 ; i < UQCOUNT_DHV; i ++){

i f ( data_to_send [ i ] > ID_DHV_NO ){return i ;

}}return UQCOUNT_DHV;

}

. . .

command uint8_t DhvVectorCache . nextItem ( ) {dhv_index_t i ;

for ( i = 0 ; i < UQCOUNT_DHV; i ++){i f ( vector_to_send [ i ] > ID_DHV_NO){

return i ;}

}return UQCOUNT_DHV;

}. . .

Abbildung 3.1.: Codeausschnitt aus Datei /tinyos-2.x/tos/lib/net/dhv/DhvVersionP.nc. Das InterfaceDhvCache wird zweimal instantiiert als DhvDataCache und DhvVectorCache und diebeide Instanzen implementieren das Kommando nextItem() in derselben Weise.

3.1.2. Testwerkzeug

Das Testwerkzeug sind die bereits im Kapitel 2.2.4 beschriebene Klondetektoren CCFind-er, Ccdiml und Deckard. CCFinder fällt in die Kategorie tokenbasierter Verfahren.Ccdiml und Deckard fallen in die Kategorie baumbasierter Verfahren.

Es war bis zu der Fertigstellung dieser Arbeit noch kein Klondetektor bekannt, welchermit nesC auf Lauffähigkeit oder Performance getestet wurde. Text- und tokenbasierteKlondetektoren sind aufgrund der angewandten Techniken sprachunabhängig. Aber einigeKlondetektoren haben einen programmiersprachespezifischen Preprocessing-Schritt, wom-it die programmiersprachespezifische syntaktische Informationen aus dem Quellcode aus-gelesen und für eine verbesserte Darstellung im jeweiligen Zwischenformat des Quellcodesverwendet werden. Die baumbasierten Klondetektoren sind generell mit nesC Quellcodenicht lauffähig, weil der Parser die Programmiersprache nicht erkennen oder nicht richtigparsen kann. Bei Deckard kann ein Einsatz auf nesC Quellcode gezwungen werden, aber

30

3.2 Vorbereitung

dann ist das Ergebnis auch nicht mehr akkurat1.

3.2. Vorbereitung

Um der Test effektiver und akkurater zu gestalten, muss eine Vorbereitungsphase einge-führt werden. Die Gründe dafür sind folgendes: Erstens verwenden die Klondetektorendiverse Parameter für die Detektion. Mit unterschiedlichen Parameterkombinationenkann ein Klondetektor sehr unterschiedliche Testergebnisse produzieren. Zweitens ergibtsich, wenn jedes Protokoll mit jedem anderen verglichen wird und noch mit unter-schiedlichen Parameterkombinationen, eine sehr hohe Anzahl von Testergebnissen unddamit verbundener Zeitaufwand. Es ist aber vielleicht gar nicht nötig, jedes Protokollmit jedem anderen zu vergleichen, da manche Protokolle unterschiedliche Routingalgo-rithmen verwenden. Drittens kann, wie bereits erwähnt, ein Quellcode in nesC nicht vonden Parsern der Klondetektoren korrekt erkannt werden. Dadurch sind die Ergebnissenicht akkurat und in schlimmsten Fall wird der Klondetektor gar nicht funktionieren.

In folgenden Abschnitte werden die betroffenen Vorbereitungsschritte vorgestellt underklärt. Damit sollen die oben genannten drei Problemfeldern vor dem eigentlichen Testbehandelt werden.

3.2.1. NesC nach C Transformation

Nicht die alle 19 Routingprotokolle sind in nesC geschrieben. WSNS und Contiki sind inC geschrieben. Wir haben also eine heterogene Testumgebung hinsichtlich der Program-miersprachen. Die Unterschiede zwischen den Syntax der Programmiersprachen könntedie Anzahl von False-Negativen erhöhen.

Zudem war bis zu der Fertigstellung dieser Arbeit noch kein Klondetektor bekannt,welcher mit nesC auf die Lauffähigkeit oder die Performance getestet wurde. Aber fastalle [1] können mit der Programmiersprache C zurechtkommen. Daher ist es sinnvoll

1In einem Testlauf mit nesC-Quellcode war im Testergebnis Verletzung der syntaktischen Grenzen zubeobachten, was bei einem baumbasierten Klondetektor nicht zu erwarten ist

31

3.2 Vorbereitung

die in nesC geschriebenen Protokolle in C-Code zu transformieren, um eine homogeneUmgebung zu bekommen und damit auch akkurate und vergleichbare Ergebnisse.

3.2.1.1. Methode

Es ist nicht möglich unter TinyOS die in nesC geschriebenen Protokolle direkt in C zukompilieren. Grund dafür ist, dass bei der Kompilierung zuerst der nesC-eigene Compilernesc1 aufgerufen wird um den nesC Code in C-Code zu transformieren bevor diesermit GCC kompiliert wird. nesc1 erstellt dabei einen cgraph, welcher die Verbindungenzwischen Komponenten und dem call-graph von Funktionen repräsentiert. Während derTransformation von nesC nach C wird die Erreichbarkeit der Funktionen anhand diesesGraphen überprüft und nur die erreichbaren Funktionen werden transformiert. Daher istes notwendig eine Applikation zu kompilieren, welche ein Routingprotokoll verwendetund alle seine Schnittstellen anspricht. In der erzeugten C-Datei der Applikation lassensich die nach C transformierten Funktionen des Protokolls wieder finden. In TOS1 undTOS2 sind bereits einige Test-Applikationen mitgeliefert, die direkt verwendet werdenkönnen. In Abbildung 3.2 wird ein Beispiel für eine Transformation gezeigt. Die Strukturder in nesC geschriebenen Funktion wird in dem C Code korrekt wiedergegeben. Esist daher möglich, durch die Untersuchung des transformierten C-Codes Klone in demursprünglichen nesC-Code zu erkennen.

nesC Code

command void∗ DhvSend . getPayloadPtr ( ) {// r e t u r n s NULL i f message i s busyi f ( busy ) {

return NULL;}return c a l l NetAMSend . getPayload (&am_msg, 0 ) ;

}

C Code

s t a t i c void ∗AMDhvP__DhvSend__getPayloadPtr ( void ){

i f (AMDhvP__busy) {return ( void ∗ ) 0 ;

}return AMDhvP__NetAMSend__getPayload(&AMDhvP__am_msg, 0 ) ;

}

Abbildung 3.2.: Transformation von nesC-Code in C-Code aus der Datei AMDhvP.nc im TOS1

32

3.2 Vorbereitung

3.2.1.2. Transformationsregeln

Die Testapplikationen verwenden nicht jede Funktion der Module, dementsprechendwird die betroffene Funktion nicht in dem C-Code der Applikation auftauchen. In solcheinem Fall muss die Funktion manuell transformiert werden, wenn die Funktion inden Test einbezogen werden soll. Durch Vergleich zwischen den originalen *.nc-Dateienund transformierten *.c-Dateien konnten folgende Transformationsregeln herausgefun-den werden:

• Funktionsname besteht aus Modulname, Interfacename und Commandname. ImTOS1 werden die 3 Komponenten mit "$"verbunden, im TOS2 mit "__". Beispiel:das Kommando selectNextHop() im Interface Neighborhood vom Module Net-workMultiHopP wird zu NetworkMultiHopP__Neighborhood__selectNextHop()transformiert. Bei Default-Funktionen wird zusätzlich zu der obigen Regel noch dasWort "defaultßwischen dem Interfacenamen und dem Commandnamen gesetzt.

• Dem Namen eines modul-spezifischen globalen Parameters wird der Modulnamevorgesetzt, verbunden mit o.g. Verbindungssymbolen.

• Der Interfaceparameter in parametrisierten Funktionen wird in die reguläre Pa-rameterliste eingefügt, z.B. ICMPPing.ping[uint16_t client](struct in6_addr *tar-get, ...) wird in ICMPResponderP__ICMPPing__ping(uint16_t client, structin6_addr *target, ...) transformiert.

• atomic wird durch den in der Abbildung 3.3 gezeigten Ausdruck ersetzt.

{ __nesc_atomic_t __nesc_atomic = __nesc_atomic_start ( ) ;. . .__nesc_atomic_end ( __nesc_atomic ) ; }

Abbildung 3.3.: atomic-Block übersetzt in C

• Alle Funktionen sind static. Command, Event und Task werden durch Static er-setzt.

• Ausführung eines Tasks, wird z.B. von "post TimerTask()ïn"TOS_post(MultiHopLEPSM__TimerTask)"transformiert.

33

3.2 Vorbereitung

• call und signal werden entfernt.

Die Transformation bringt sowohl Vor- als auch Nachteile mit sich.

Die Vorteile sind:

• Die Transformation ermöglicht den Einsatz für baumbasierte Klondetektoren. Nochist kein baumbasierter Klondektektor bekannt, welcher auf nesC-Programme an-wendbar ist. Aufgrund der Tatsache, dass solche Klondetektoren den Quellcodeparsen müssen, ist deren Einsatz für nesC-Quellcode unmöglich.

Die Nachteile sind:

• Während der Transformation werden viele Typ-1-Klone zu Typ-2-Klonen durchUmbenennung der Funktionen, und mache Type-3-Klone zu Typ-2-Klonen durchdie Entfernung der Debugfunktionen. Das macht den Typen-Report vom Klonde-tektor unbrauchbar. Um die tatsächlichen Typen der gefundenen Klonen feststellenzu können, muss der originale Quellcode zusätzlich analysiert werden.

• Es gibt in den Protokollen Codefragmente, die per #ifdef (z.B. plattformspezifischeKonstante) bedingt eingebunden sind und in der Testapplikation aufgrund derfehlenden Bedingungen nicht immer übersetzt werden. Diese müssen dann manuelltransformiert werden.

• Der transformierte Code der Testapplikation beinhaltet noch viele zusätzliche ap-plikationsspezifische, plattformspezifische Codes, so hat z.B. die Testapplikationfür Dhv 23229 SLOC2, nur 1262 SLOC davon gehören zu dem transformierten Pro-tokoll Dhv selbst. Es ist daher notwendig den Quellcode des Protokolls aus demApplikationscode heraus zu suchen und in der ursprünglichen Struktur zusam-menzufassen. Da dieser Schritt manuell getätigt wird, kann sich dieser Fehler trotzsorgfältiger Arbeitsweise dadurch einschleichen.

• Durch die Entfernung von Kommentaren und Debugfunktionen weichen die Statis-tiken über LOC, die vom Klondetektor berichtet werden, von der tatsächlichenAnzahl von duplizierten Codezeilen ab.

2Code Zeilen ohne Kommentare und Leerzeilen, getestet mit dem Tool CLOC, Homepage:http://cloc.sourceforge.net/

34

3.2 Vorbereitung

Da der Vorteil der Transformation direkt dazu führt, dass mehr Klone gefunden wer-den und mehr Klondetektoren eingesetzt werden können, werden die Nachteile in dieserArbeit in Kauf genommen. Es wäre aber wünschenswert, die Statistiken der Klontde-tektoren direkt verwenden zu können und weniger manuelle Eingriffe vornehmen zumüssen.

3.2.2. Bestimmung der Testparameter

Jeder Klondetektor erlaubt die Detektion mit diversen Parametern. Eine sorgfältigeAuswahl der Parameter ist essentiell für ein akkurates Ergebnis der Untersuchung. DasZiel dieser Arbeit, in sich abgeschlossene funktionelle Codeblöcke wie eine Funktionsdef-inition oder eine längere Sequenz von Statements, die einen komplexen Verarbeitungss-chritt oder eine Logik im Ablauf einer Funktion darstellen, wird als das Grundprinzip fürdie Bestimmung der Testparameter gesetzt. Dieser Anschnitt zielt darauf, das jeweiligeoptimale Parameterset für die Untersuchung zu ermitteln. Durch manuelle Analyse derQuellcodes vom Dhv (tinyos-2.x/tos/lib/net/dhv/), lassen sich zahlreiche Typ-2- undTyp-3-Klone identifizieren. Aufgrund dessen wird Dhv zwecks Bestimmung der Param-eter als Testgegenstand eingesetzt.

3.2.2.1. CCFinder

CCFinder erlaubt eine Klon-Detektion mit 4 Einstellungsmöglichkeit: Minimum CloneLength (MCL), Minimum TKS (MTKS), Shaper Level (SL) und P-match Application.

Die P-match Applikation ermöglicht eine charakterisierende Tokenisierung für unter-schiedliche Variablen- und Funktionsnamen. SL gibt an, wie stark sich an die Grenzensyntaktischer Codeblöcke gehalten wird. Es existieren 4 SL-Stufen, hard sharper, softsharper, easy sharper und without sharper. Mit hard sharper wird nur eine Tokensequenz,die innerhalb eines syntaktischen Blocks eingeschlossen ist, als einen Klon-Kandidat aus-gegeben. Diese Einstellung entspricht genau der Anforderung und wird deshalb einge-setzt. Weitere Information über die anderen SL-Stufen gibt es hier [15].

Die Auswahl von MCL und MTKS sind nicht mehr so straightforward. Der Parame-

35

3.2 Vorbereitung

return x + y −> return $ + $return a + a −> return $ + $

Transformationohne P-matching

return x + y −> return $1 + $2return a + a −> return $1 + $1

Transformationmit P-matching

Abbildung 3.4.: Beispiel für P-matching in CCFinder

ter MCL ist die minimale Anzahl von Token, welche ein Klon-Kandidat besitzen muss.Das heißt, je größer die Länge ist um so mehr Zeilen umfasst der Klon-Kandidat. MTKSist die minimale Anzahl unterschiedlicher Token, je größer die Zahl ist, um so kom-plexer ist der Klon-Kandidat. MCL und MTKS müssen gleichzeitig erfüllt werden. DieKomplexität des Codes in der Abbildung 3.5 entspricht 39-13, also MCL = 39 undMTKS = 13. Die minimale Komplexität der in dieser Arbeit gesuchten Klone wur-den damit auf 30-10 geschätzt, also ähnlich wie der Code in der Abbildung 3.5, aberohne Array und Funktionsaufruf im Zuweisungsstatement. Um die Plausibilität diesesParametersets zu überprüfen, werden Tests mit 4 MCL-MTKS Sets, 15-5, 20-10, 30-10und 45-15 durchgeführt und die Ergebnisse analysiert. Siehe Abbildung ??, Tabelle 3.1und Anhang Tabelle A.1 für ausführliche Details.

for ( i = 0 ; i < 2U; i ++) {DipVectorP__pairs [ i ] . key = DipVectorP__DipHelp__indexToKey ( i ) ;DipVectorP__pairs [ i ] . e s t i m a t e = e s t s [ i ] ;

}

Abbildung 3.5.: Ein Codesegment aus DipVectorP.c mit MCL-MTKS = 30-13

15-5 20-10 30-10 45-15Typ 1 2 1 1 0

Typ 2-k 21 13 7 2Typ 2-ik 0 0 0 0

Typ 3 0 0 0 0

Tabelle 3.1.: Parametertuning für CCFinder mit C-Code vom Dhv. Testergebnis hinsichtlich Klon-typen mit jeweiligem Parameterset ohne Berücksichtigung auf die Relevanz der Klone.k=konsistent, ik=inkonsistent

Erläuterung der Abbildung 3.6:

Parameterset 15-5: Mit diesem Set ergaben sich 27 Klonkandidaten3. Davon 4 sind falsch

3In CCFinder ist ein Klonkandidat eine Klonklasse.

36

3.2 Vorbereitung

Abbildung 3.6.: Parametertuning für CCFinder mit C-Code vom Dhv. Jede Säule stellt die gesamteMenge der vom CCFinder mit jeweiligem Parameterset gefundenen Klonkondidaten dar.Der rote Bereich stellt die False-Positiven dar, der darunter liegende türkis Bereich zwarKlone, die aber nicht für diese Arbeit relevant sind, der grüne Bereich die relevantenKlone.

37

3.2 Vorbereitung

positiv. 15 aus den 23 Kandidaten, die wirklich Klone sind, bestehen aus Hintereinander-folgen von einfachen Statements, woraus sich keine bedeutende Semantik ziehen lässt.Die restlichen 8 bestehen aus funktionellen Blöcken wie if-else, Funktionsblcken oderzusammengesetzten Funktionsblöcken.

Parameterset 20-10: Mit diesem Set ergaben sich 22 Klonkandidaten, alle sind wirklichKlone. 14 davon bestehen aus Hintereinanderfolgen von einfachen Statements, woraussich keine bedeutende Semantik ziehen lässt. Die restlichen 8 sind identisch mit denenaus Parameterset 15-5.

Parameterset 30-10: Mit diesem Set ergaben sich 8 Klonkandidaten, alle sind wirklichKlone. 2 davon bestehen aus Hintereinanderfolgen von einfachen Statements, woraus sichkeine bedeutende Semantik ziehen lässt. Die restlichen 6 bestehen aus Funktionsblckenoder zusammengesetzten Funktionsblöcken.

Parameterset 45-15: Mit diesem Set ergaben sich 2 Klonkandidaten. Sie bestehen ausfunktionellen Blöcken oder zusammengesetzten Funktionsblöcke mit hoher Komplexität(längerer Funktionsrumpf, if - und for-Blöcke).

Mit dem Parameterset 15-5 konnten viele Klone gefunden werden, aber mit hoher Ratevon False-Positiven (4 in der Abbildung 3.6). Mit den Parametersets 20-10 und 30-10können alle oder fast alle relevanten Klonen wieder gefunden werden ohne False-Positive.Bei 20-10 ergab sich aber eine hohe Anzahl (14 in der Abbildung 3.6) von irrelevantenKlonen, was den Analyseaufwand gegenüber 30-10 um fast das 3-fache erhöht (22 zuanalysierende Klone mit 20-10, 8 zu analysierende Klone mit 30-10). Daher wird alsKompromiss für die spätere Untersuchung der Protokolle mit CCFinder das Parameter-set MCL-MTKS: 30-10 mit hard sharper genommen.

Bei den Ergebnissen aller Sets wurden keine Klonkandidaten gefunden, welche die syn-taktische Blockgrenze verletzt haben. Dies liegt an die Verwendung vom hard sharper.Die soft und easy sharper sind genau so effektiv in diesem Fall, aber ohne sharper sindVerletzungen der syntaktische Grenzen zu beobachten, was für einen tokenbasiertenKlonedetektor üblich ist.

38

3.2 Vorbereitung

3.2.2.2. Deckard

Deckard erlaubt die Einstellungsmöglichkeit in 3 Parametern: minimal token size (MTS),stride und similarity (SIM).

Eine kurze Wiederholung vom Katital 2.2.4.3: Deckard berechnet zunächst die charak-teristischen Vektoren für die Teilbäume im euklidischen Raum um die strukturelle In-formation des AST zu approximieren, dann werden die ähnlichen Vektoren anhand dereuklidischen Distanz der Vektoren gruppiert. Anschließend wird unter der Verwendungvom LSH in jeder Gruppe nach Klonen gesucht. LSH verwendet dabei einen Schwellen-wert σ um die ähnlichen Knoten in Verbindung zu bringen. Für bessere Verständigungzunächst ein Paar Definitionen:

Definition 3.2.1 Editing Distance The editing distance of two trees T1 and T2, de-noted by δ(T1, T2), is the minimal sequence of edit operations (either relabel a node, inserta node, or delete a node) that transforms T1 to T2.[10]

Definition 3.2.1 Tree Similarity Two trees T1 and T2 are σ-similar for a giventhreshold σ, if δ(T1, T2) < σ.[10]

Definition 3.2.1 Clone Pair Two code fragments C1 and C2 are called a clone pairif their corresponding tree representations T1 and T2 are σ-similar for a specified σ.[10]

Deckard verwendet eine ähnliche Definition für Ähnlichkeit (similarity) wie ClonDR [9],und verwendet auch dessen Definition um σ zu berechnen.

Similarity(T1, T2) = 2H

2H + L + R(3.1)

Das H ist die Anzahl gemeinsamer Knoten in den Bäumen T1 und T2. L ist die Nummerder unterschiedlichen Knoten in T1, und R ist die Nummer der unterschiedlichen Knotenin T2. Die Formel für die Berechnung von σ für die Vektoren (υ) in einer Vectorgruppe(ν) lautet

σ =√

2(1 − s) × minυ∈νS(υ) (3.2)

39

3.2 Vorbereitung

In der Formel 3.2 steht das s für similarity und das S(υ) für die Größe des mit dem Vektorkorrespondierenden Baumfragments, approximiert durch die Quersumme des Vektors.

Es ist schwierig für die Bestimmung der Parameter die similarity direkt durch Formel3.1 zu bestimmen, da der AST noch unbekannt ist, daher werden die similarities mit derFormel 3.2 umgekehrt mit σ als Parameter berechnet. Die Ergebnisse werden in Tabelle3.2 dargestellt.

σ S(S(ν))20 30 40

1 0,98 0,98 0,992 0,90 0,93 0,953 0,78 0,85 0,894 0,60 0,73 0,80

Tabelle 3.2.: similarity berechnet aus dem Schwellenwert σ und der Vektorgröße S(ν).

In [10] wird ein Beispiel gezeigt mit einem for-Block, welches die Vektorgröße 15 be-sitzt. Im Zusammenhang mit den Ergebnissen aus dem vorherigen Abschnitt wurdehierbei die Vektorgröße, bzw. der Parameter token size auf 30 geschätzt. Der Parameterstride beschreibt die Schiebefenstergröße. Da die Funktionen in den Protokollen meistrelativ kurz sind, wurde daher dieser Parameter auf 0 gesetzt, also das Schiebefensterdeaktiviert.

for ( int i = 0 ; i < n ; i ++)x [ i ] = 0 ;

Abbildung 3.7.: Ein Beispiel aus [10] mit Vektorgröße 15

Aufgrund der Transformation von nesC-Code in C-Code, ist es zu erwarten, dass dieFunktionen, auch wenn sie ursprünglich identischen sind, also Typ-1-Klone, nun durchdie Umbenennung des Bezeichners zu Typ 2-Klon geworden sind. Das heißt, der Param-eter σ muss mindestens den Wert 1 betragen, also muss eine Umbenennungsoperationdurchgeführt werden, so dass zwei Codefragmente identisch werden. Mit der Überlegungdass für eine kleine Funktion (mit nur 2 oder 3 Zeilen) wahrscheinlich nur eine Op-eration ausreicht für eine Übereinstimmung, benötigen größere Funktionen mehr. ImZusammenhang mit der Tabelle 3.2 wurden für den Test die Parametersets (MTS-SIM)20-0,90, 20-0,98, 30-0,85 und 30-0,93 genommen.

40

3.2 Vorbereitung

Abbildung 3.8.: Parametertuning für Deckard mit C-Code vom Dhv. Jede Säule stellt die gesamte Mengeder vom Deckard mit jeweiligem Parameterset gefundenen Klonkandidaten dar. Der roteBereich stellt die False-Positiven dar, der darunter liegende türkise Bereich zwar Klone,die aber nicht für diese Arbeit relevant sind, der grüne Bereich die relevanten Klone.

41

3.2 Vorbereitung

Mit den Ergebnissen in der Abbildung 3.8 wurde sehr deutlich, dass mit dem Parame-terset 20-0,90 mit Abstand die meisten Klone (24, zum Vergleich: 19 mit Parameterset20-0,98 auf Platz 2) finden. Dabei bleibt auch die Anzahl von False-Positiven auf einemakzeptablen Niveau (6, entspricht 20% der gemeldeten Kandidaten). Die Kriterien fürdie Unterteilung der relevanten und irrelevanten Klonen ist in der Erläuterung der Ab-bildung ?? im Kapital 3.2.2.1 beschrieben. Detaillierte Testergebnisse siehe Tabelle imAnhang A.3

3.2.2.3. Ccdiml

Ccdiml verwendet viele Parameter, welche aber leicht verständlich und selbsterklrendsind.

Die wichtigsten Parameter sind mode, minlines, mindepth, minweight und type3gap. Mitdem Parameter mode kann man festlegen, zu welchem Level ein Programm untersuchtwerden soll, Routinelevel (routines), Statementlevel (coarse) oder auch jede einzelneStatements in einer Statementsequenz (fine). Für den Test wird mode auf fine gesetzt.Minlines beschreibt die minimale Länge von einem Klonkandidaten in Codezeilen, hi-er wird 5 als das Minimum für den Test gesetzt, denn 5 ist die minimale Anzahl vonCodezeilen, welche die in dieser Arbeit gesuchten Klone haben sollen. Das Mindepthbeschreibt die minimale Tiefe eines Teilbaums im AST, das minweight beschreibt dieminimale Anzahl von Knoten eines Teilbaums, beide Parameters werden auf dem Stan-dardwert 1 belassen. Der Parameter type3gap beschreibt das Gap (2.2.3) zwischen zweiTyp-2 oder Typ-1-Klonen, die zu einem Typ-3-Klon zusammen gesetzt werden können,gemessen in Anzahl von Blätterknoten im AST. Das Gap wird zunächst auf den Stan-dardwert 2 gesetzt.

Es wurden zunächst Tests durchgeführt mit den Parametersets minlines-type3gap: 5-2, 6-2. Die Ergebnisse werden in der Tabelle 3.3 und der Abbildung ?? dargestellt. DieAbbildung ?? zeigt, dass die durch den Test mit 5-2 gefundenen Klonen (24) bereitsalle Klone von dem Test mit 6-2 (20) decken, 5-2 aber eine höhere Anzahl (13) vonuninteressanten Klonen verursacht als 6-2 (9). Um die als Typ-3-Klone4 gemeldeten

4Im Vergleich von Tabelle 3.3 und Tabelle 3.1 wird der Vorteil von baumbasierten Verfahren gegenübertokenbasierten Verfahren ersichtlich, dass baumbasierte Verfahren auch Typ-3-Klone entdecken kn-

42

3.2 Vorbereitung

False-Positiven (7 von 8, siehe Anhang Tabelle A.5) zu reduzieren wurde ein weitererTest mit 5-1 durchgeführt. Das Parameterset 5-1 verursacht dabei weniger als die Hälfte(6) uninteressante Klone, weniger False-Positive in Typ-3 (5 von 6, siehe Anhang TabelleA.7) und findet fast alle (23 von 24) relevanten Klone wieder. Daher wird das Parameter-set minlines-type3gap: 5-1 für die Untersuchung der Protokolle eingesetzt. Die Kriterienfür die Unterteilung der relevanten und irrelevanten Klonen ist in der Erläuterung derAbbildung ?? im Kapital 3.2.2.1 beschrieben.

5-2 6-2 5-1Typ 1 4 4 4

Typ 2-k 18 13 18Typ 2-ik 0 0 0

Typ 3 15 12 7

Tabelle 3.3.: Parametertuning für Ccdiml mit Objektdatei der Testapplikation für Dhv. Testergebnishinsichtlich Klontypen mit jeweiligem Parameterset ohne Berücksichtigung der Relevanzder Klone. k=konsistent, ik=inkonsistent

Abbildung 3.9.: Parametertuning für Ccdiml mit Objektdatei der Testapplikation für Dhv. Jede Säulestellt die gesamte Menge der von Ccdiml mit jeweiligem Parameterset gefundenenKlonkondidaten dar. Der rote Bereich stellt die False-Positiven dar, der darunterliegende türkise Bereich zwar Klone, die aber nicht für diese Arbeit relevant sind, dergrüne Bereich die relevante Klone.

nen.

43

3.2 Vorbereitung

3.2.2.4. Zusammenfassung

Anhand der Testergebnisse der in den vorherigen Abschnitten beschriebenen Tests,wurde das Parameterset MCL-MTKS für CCFinder auf 30-10, das Parameterset minlines-type3gap für Ccdiml auf 5-1 gesetzt und das Parameterset MTS-SIM für Deckard auf20-0,90 gesetzt.

Die von den Klondetektoren gefundenen Klone wurden nicht hinsichtlich der Anzahlund der Qualität verglichen, denn dieser Testschritt sollte lediglich sicherstellen, dassfür jeden Klondetektor die jeweilige optimale Parameterkombination zu finden. Es flltjedoch bereits hier auf, dass CCFinder wesentlich schneller ist und Ccdiml Typ-3-Kloneentdecken kann. Einen ausfhrlichen qualitativen Vergleich der Klondetektoren findetman in [1].

3.2.3. Kategorisierung der Routing Protokolle

Um die Komplexität und den damit verbundenen Zeitaufwand zu reduzieren, und wasnoch wichtiger ist, die Protokolle gezielter und sinnvoller miteinander zu vergleichen,wurden sie in 5 Kategorien unterteilt. Es wurde für wahrscheinlicher angenommen, dassdie Protokolle innerhalb einer Kategorie mehr oder überhaupt Ähnlichkeiten aufweisen.Die Kriterien dafür wurden aus den Studien der jeweiligen Literatur und durch manuelleBetrachtung des Quellcodes gewonnen und in folgender Hinsicht gestellt: Rolle des Nodes(Multihop, Node als Sender/Router), Zweck der Protokolle (Collection, Dissemination),Routingstruktur (Tree, Mesh).

Es gibt noch andere Aspekte für eine Kategorisierung, wie z.B. der beteiligte Autor5.Diese Informationen sind zwar nicht essentiell, konnte aber durch die in dieser Arbeitgezeigte Kategorisierung einigermaßen gedeckt werden. Während der Kategorisierungmittels Literatur fallen bereits einige Protokolle auf, die potenziell einen hohen Anteilvon Klonen enthalten könnten. So wurden Dhv und Dip beide aus TinyOS 2.x entnom-men und von demselben Entwicklerteam implementiert. Dazu benutzen die Protokolle

5Gilman Tolle hat sich an der Entwicklung von Drain, Dhv, Drip, Dip und Lqi beteiligt, Philip Levisan der Entwicklung von Blip, Ctp, Lqi, Route, MultiHop, Dhv und Dip.

44

3.3 Umsetzung

Protokolle Projekt KategorieMultihop Collection Dissemination Tree Mesh

uAODV Contiki cContikiRPL Contiki cWSNS WSN-Siml. cDrip TOS2 c,o c,oDip TOS2 c,oDhv TOS2 c,oCtp TOS2 c,o c,oLqi TOS2 c,oTymo TOS2Blip TOS2 c,oZigbee TOS2 c,oSensorscope Sensorscope c,oTinyAODV TOS1 cDSDV TOS1Flood TOS1MintRoute TOS1 c cRoute TOS1 cDrain TOS1 c cMultihopLQI TOS1 c c

Tabelle 3.4.: Kategorisierung der Routingprotokolle: In jeder Kategorie werden die dazugehörigen Pro-tokolle mit dem verwendeten Klondetektor gekennzeichnet, c für CCFinder und Deckard,o für Ccdiml.

noch gemeinsam den Trickle-Alogrithmus6. Die Literatur der Protokolle weisen auchbereits auf einige Ähnlichkeiten hin. Es war also zu erwarten, dass viele Klone zwischenden beiden Protokollen zu finden sein werden.

3.3. Umsetzung

In dieser Arbeit sollten 19 Routing Protokolle für WSN mit 3 Klonerkennungstoolsauf duplizierten Code untersucht werden. Nach der Vorbereitungsphase wurden 16 Pro-tokolle in 5 Kategorien nach der Vergleichbarkeit unterteilt. Die restlichen 3 Protokolle,Tymo, DSDV und Flood wurden aufgrund der fehlenden Vergleichbarkeit nicht unter-sucht.

Von den drei Klondetektoren wurden nur CCFinder und Deckard für die Untersuchungaller Protokolle angewandt. Ccdiml benötigt eine Objektdatei um den AST zu bilden,und diese Objektdatei muss mit dem Ccdiml-eigenen C-Compiler cafeCC kompiliertwerden. Während dieser Arbeit konnten nur die Testapplikationen im TinyOS 2.x mitcafeCC erfolgreich kompiliert werden. Demzufolge wurden nur die Protokolle, die fürdiese Applikationen verwendet wurden, mit Ccdiml untersucht. Die Ergebnisse vomCcdiml dienen daher ggf. nur als Ergänzung.

6Trickle ist ein selbstregulierender Algorithmus für Codeverbreitung und -wartung in WSNs

45

3.3 Umsetzung

Zusammenfassung: In dieser Arbeit wurden 16 Routingprotokolle untersucht. Die Un-tersuchung zielt auf die Funktionen, die in den Protokollen implementiert werden. Da-her wurden Header und Configurations (in der TinyOS-Umgebung, TinyOS 1.x, 2.xund Sensorscope) nicht untersucht. Die Protokolle wurden in 5 Kategorien unterteilt.Jede Kategorie wurde mit 2 Klondetektoren untersucht. Alle 16 Protokolle konnten mitCCFinder und Deckard untersucht werden, nur die 5 Protokolle aus TinyOS 2.x konntenmit Ccdiml untersucht werden.

46

4. Auswertung der Testergebnisse

In dieser Arbeit wurden WSN-Routingprotokolle auf Codeduplikationen im Quellcodeuntersucht. Das Augenmerk wurde hierbei auf in sich abgeschlossene funktionelle Code-blöcke wie eine Funktionsdefinition oder eine längere Sequenz von Statements gerichtet,die einen komplexen Verarbeitungsschritt oder eine Logik im Ablauf einer Funktiondarstellen. Diese Zielsetzung wurde bereits in der Parametereinstellung der Klondetek-toren berücksichtigt und wird in der Auswertung der Testergebnisse wieder umgesetzt,indem die uninteressanten Klone nicht in der Statistik erfasst werden.

In den folgenden Abschnitten wird zunächst das Auswertungsverfahren erläutert. Dannwerden die Auswertungen der Klone in der Kategorie-, Protokoll- und Datei-Ebene aus-getragen. Anschließend folgt eine Beurteilung der Klondetektoren.

4.1. Auswertungsverfahren

Die Testergebnisse sind sehr umfangreich. Sie enthalten Informationen über die Verteilungder Klone in Kategorien, Protokollen und Dateien, Information über Klontypen undKlonlänge. Es ist daher wichtig, einige Grundregeln festzulegen, um während der Anal-yse immer den Überblick behalten zu können und die Analyseergebnisse nachvollziehbarzu machen. Folgende Regeln wurden für die Auswertung der Testergebnisse verwendet:

• Sei gegeben eine Klonklasse KK{κ1, κ2, κ3}, κ1,2,3 bezeichnen drei Klone, die zu derKlonklasse KK gehören, befinden sich weiter κ1 und κ2 beide im Protokoll Pa, undκ3 im Protokoll Pb. Angenommen SLOCPa = m, SLOCPb

= n, SLOCκ1,2,3 = p,dann hat KK den Anteil (2 ∗ p)/m in Pa und p/n in Pb.

47

4.2 Auswertung

• Wenn eine Klonklasse KK1 bereits in einer anderen Klonklasse KK2 vollständigenthalten ist, dann wird nur KK2 in die Statistik einfließen.

Für nesC-Protokolle wurden die Klonkandidaten manuell vom transformierten C-Codeauf den originalen nesC-Code zurück abgebildet und auf Klontypen, SLOC und Popula-tion gemäß oben genannten Regeln untersucht. Die SLOC der Dateien, Protokolle undKategorien werden im Anhang A.4 aufgelistet.

4.2. Auswertung

Für die Auswertung wurden die Testergebnisse aller Klondetektoren zusammengefasst.Klondetektorspezifische Ergebnisse werden im Abschnitt 4.3 diskutiert.

Die Auswertung wird in drei Schritten ausgetragen. Es werden zunächst die Statistikender Klonklassen auf der Kategorie-Ebene gezeigt und erläutert. Wenn in einer Kate-gorie Klone gefunden wurden, werden die Ähnlichkeitsgrade der Protokolle im zweit-en Schritt präsentiert und erläutert. Die Protokolle mit besonders hohen Ähnlichkeits-graden, MintRoute und Route bzw. Dip und Dhv, werden im dritten Schritt auf derDatei-Ebene näher betrachtet.

4.2.1. Statistik auf der Kategorie-Ebene

In der Tabelle 4.1 werden die in jeweiliger Kategorie gefundenen Klonklassen (KK) mitSLOCKK , Population (pop), SLOCDurchschnitt, Klontyp und Ist-Funktion dargestellt.Dabei ist SLOCKK das gesamte SLOC aller Klone in KK, Population die Anzahl derKlone in der KK, SLOCDurchschnitt das durchschnittliche SLOC eines Klons in KKund DSLOC das durchschnittliche SLOC eines Klons in der Kategorie, berechnet ausSum(gSLOC)/Sum(pop). Die Ist-Funktion sagt aus, ob die Klone komplette Funktion-blöcke sind. Die Tabelle 4.2 zeigt den Anteil geklonten Codes in jeweiliger Kategorie. DerAnteil berechnet sich für die jeweilige Kategorie aus Sum(gSLOCKlone)/SLOCKategorie .In der Kategorie Multihop enthalten die Klonklassen von 16 bis 19 jeweils mindestens2 Klone, die bereits in der Klonklasse 1 inbegriffen sind, deren SLOC werden in der

48

4.2 Auswertung

Berechnung für die Tabelle 4.2 nicht wiederholt verwendet.

Es konnte in den Tests überwiegend komplette Funktionblöcken gefunden werden. Daserfüllt genau das Ziel dieser Arbeit, zwar die gleiche oder ähnliche Funktionalitätenzwischen den Protokollen zu finden, die sich eventuell modularisieren lassen können.Und Komplette Funktionblöcke eignen sich am besten dafür.

Es konnte in der Kategorie Tree kein Klon zwischen den Protokollen gefunden werden.In der Kategorie Collection konnten nur zwei Klonpaare gefunden werden, mit durch-schnittlicher Länge von 7 und 8 Codezeilen. Die Kategorie Mesh liefert 5 Klonklasse an11 Stellen, darunter einen relativ langen Code-Klon mit 16 Codezeilen. Die KategorieDissemination weist sowohl eine hohe Anzahl von Code-Klonen (12 Klonklassen an 31Stellen verteilt) als auch einen hohen Anteil geklonten Codes (17,18%) auf. Die Kate-gorie Multihop weist zwar die höchste Anzahl von Code-Klonen (15 Klonklassen an 38Stellen verteilt) auf, hat aber nur einen Anteil geklonten Codes von 6,80% aufgrund derhohen Anzahl von Protokollen. In den Kategorien Dissemenation und Multihop wurdenauch sehr große Klone mit über 30 SLOC gefunden.

Es wurden Klone vom Typ 1, Typ 3 und Typ 2 mit konsistenter Umbenennung (imnachfolgenden Teil dieser Arbeit einfach Typ 2 genannt) gefunden. In den KategorienCollection, Mesh und Dissemination wurden berwiegend Typ-2-Klone gefunden, in derKategorie Multihop jedoch eine hohe Anzahl von Typ-1-Klonen. Das dSLOC bewegtsich für gewöhnlich zwischen 5 und 20, jedoch gibt es in Dissemination und MultihopAusreißer mit dSLOC weit über 20. Dadurch werden auch die DSLOC in diesen bei-den Kategorien deutlich erhöht. Speziell für die in nesC geschriebene Protokolle (alle3 in Dissemination und 6 von 8 in Multihop) könnte das alles darauf hindeuten, dasseventuell einige Module ohne oder nur mit wenigen Modifikationen von mehreren Pro-tokollen verwendet werden. Eine Untersuchung in dieser Hinsicht wird im Abschnitt ??erläutert.

4.2.2. Ähnlichkeitsgrade von Protokollen

Dieser Auswertungsschritt dient dazu, diejenigen Protokolle mit hoher Ähnlichkeit zulokalisieren. Diese werden dann im Abschnitt 4.2.3 auf der Datei-Ebene näher unter-

49

4.2 Auswertung

TreeKlonklasse gSLOC Population dSLOC Klontyp Ist-Funktion

0 0 0 0KK Anzahl Sum(gSLOC) Sum(pop) DSLOC

0 0 0 0

CollectionKlonklasse gSLOC Population dSLOC Klontyp Ist-Funktion

1 16 2 8,0 3 y2 14 2 7,0 2 y

KK Anzahl Sum(gSLOC) Sum(pop) DSLOC2 30 4 7,5

MeshKlonklasse gSLOC Population dSLOC Klontyp Ist-Funktion

1 32 2 16,0 1 y2 18 3 6,0 2 y3 12 2 5,0 2 y4 10 2 5,0 3 y5 10 2 5,0 1 y


DisseminationKlonklasse gSLOC Population dSLOC Klontyp Ist-Funktion

1 84 2 42,0 2 y2 75 9 8,3 3 y3 52 2 26,0 3 y4 34 2 17,0 3 y5 31 2 15,5 2 y6 26 2 13,0 2 n7 18 2 9,0 1 y8 16 2 8,0 2 y9 16 2 8,0 2 n

10 12 2 6,0 2 y11 12 2 6,0 2 y12 11 2 5,5 2 y


MultihopKlonklasse gSLOC Population dSLOC Klontyp Ist-Funktion

1 147 2 73,5 1 y2 64 2 32 3 y3 60 2 30 1 y4 32 2 16 1 y5 30 2 15 1 y6 27 3 9 2,3 y7 26 2 13 1 n8 24 4 6 1,2 y9 20 2 10 1 y

10 18 2 9 3 n11 16 2 8 1 y12 14 2 7 1 y13 14 2 7 1 n14 12 2 6 3 y15 10 2 5 1 n16 49 3 16,33 1,3 y17 18 3 6 1,2 y18 40 7 5,71 1,3 y19 20 4 5 1 y


Tabelle 4.1.: Übersicht gefundener Klonklassen (KK) in jeder Kategorie. Die SLOC der Klone in einerKlonklasse können variieren, daher ist die dSLOC nicht immer ganzzahlig.

Tree Collection Mesh Dissemination Multihop0,00% 0,99% 3,26% 17,18% 6,80%

Tabelle 4.2.: Anteil geklonten Codes in jeder Kategorie.

50

4.2 Auswertung

sucht. Es wurde kein Klon in der Kategorie Tree gefunden, daher wird diese Kategoriein diesem Abschnitt nicht weiter betrachtet.

Seien gegeben zwei Protokolle P1 und P2 mit gemeinsamen Code-Klonen von n SLOC.Eine akkurate Aussage über die Ähnlichkeit der zwei Protokollen kann nicht direkt ausn getroffen werden, denn es muss die SLOC der Protokolle in Betracht gezogen werden.Während n beispielsweise 50% von SLOCP1 ausmacht, ist es für SLOCP2 nur 5%, wennSLOCP2 das Zehnfache von SLOCP1 ist. So kann man nicht eindeutig sagen, dass P1

und P2 ähnlich sind.

Um die Ähnlichkeit zweier Protokolle akkurat auszudrücken wird der Begriff Ähnlichkeits-grad eingeführt. Der Ähnlichkeitsgrad wird wie folgt definiert: Seien P1 und P2 Pro-tokolle, P1 hat m Zeilen Kloncode (in SLOC), die mit n Zeilen Kloncode im Protokoll P2

korrespondieren, dann bildet das Wertepaar ((m/SLOCP2 ∗100)%, (n/SLOCP1 ∗100)%)den Ähnlichkeitsgrad für Protokollpaar P1-P2. Zwei Protokolle eines Protokollpaares mit2 hohen Prozentwerten im Ähnlichkeitsgrad sind ähnlich, das heißt nur wenn die gemein-samen Code-Klone einen signifikanten Anteil in den jeweiligen Protokollen ausmachen.Für die Auswertung wurde der Schwellenwert 10% genommen.

Die Tabellen 4.3, 4.5, 4.4 und 4.6 bestehen jeweils aus zwei Subtabellen. Subtabelle„SLOC von Klonen “zeigt die SLOC der korrespondierenden Code-Klone zweier Pro-tokolle, z.B. die linke Subtabelle der Tabelle 4.4 zeigt, dass im MintRoute 34 SLOCCode-Klone mit 32 SLOC Code-Klonen im MultiHopLQI korrespondieren. Subtabelle„Ähnlichkeitsgrade “zeigt den Ähnlichkeitsgrad eines Protokollpaars P1-P2 getrennt inFeldern (P1, P2) und (P2, P1), z.B. in derselben Tabelle wie oben, zeigt die rechte Sub-tabelle, dass das Protokollpaar MintRoute-MultiHopLQI einen Ähnlichkeitsgrad von(7,25%, 4,27%) hat. Die Prozentzahlen eines Ähnlichkeitsgrades sind meist verschiedenaufgrund dessen, dass die Protokolle unterschiedliche SLOC haben und die Klonklasseungleichmäßig verteilt sein kann.

SLOC von KlonenCtp Lqi Drain Drip

Ctp - 15 - -Lqi 15 - - -

Drain - - - -Drip - - - -

ÄhnlichkeitsgradeCtp Lqi Drain Drip

Ctp - 1,61% - -Lqi 1,44% - - -

Drain - - - -Drip - - - -

Tabelle 4.3.: SLOC von Code-Klonen und Ähnlichkeitsgrade zwischen Protokollen in der KategorieCollection.

51

4.2 Auswertung

SLOC von KlonenMintRoute Drain MultiHopLQI Drip

MintRoute - 6 34 -Drain 6 - 11 -

MultiHopLQI 32 11 - -Drip - - - -

ÄhnlichkeitsgradeMintRoute Drain MultiHopLQI Drip

MintRoute - 2,49% 7,25% -Drain 0,8% - 2,35% -

MultiHopLQI 4,27% 1,04% - -Drip - - - -

Tabelle 4.4.: SLOC von Code-Klonen und Ähnlichkeitsgrade zwischen Protokollen in der KategorieMesh.

SLOC von KlonenDhv Dip Drip

Dhv - 209 -Dip 175 - -Drip - - -

ÄhnlichkeitsgradeDhv Dip Drip

Dhv - 23,64% -Dip 15,16% - -Drip - - -

Tabelle 4.5.: SLOC von Code-Klonen und Ähnlichkeitsgrade zwischen Protokollen in der KategorieDissemination

SLOC von KlonenMintRoute Route MultiHopLQI Blip Rpl Sensorscope TinyAODV uAODV

MintRoute - 326 34 - - - - -Route 322 - 39 - - - - -

MultiHopLQI 32 32 - - - - - -Blip - - - - - - - -Rpl - - - - - - - -

Sensorscope - - - - - - - -TinyAODV - - - - - - - -

uAODV - - - - - - - -Ähnlichkeitsgrade

MintRoute Route MultiHopLQI Blip Rpl Sensorscope TinyAODV uAODVMintRoute - 31,05% 7,25% - - - - -

Route 42,93% - 8,32% - - - - -MultiHopLQI 4,27% 3,05% - - - - - -

Blip - - - - - - - -Rpl - - - - - - - -

Sensorscope - - - - - - - -TinyAODV - - - - - - - -

uAODV - - - - - - - -

Tabelle 4.6.: SLOC von Code-Klonen und Ähnlichkeitsgrade zwischen Protokollen in der KategorieMultihop

52

4.2 Auswertung

Die SLOC der korrespondierenden Code-Klone von MintRoute und MultiHopLQI wer-den in den Tabellen 4.6 und 4.4 zweimal dargestellt, berechnet aus dem Testergebnis desjeweiligen Testlaufs. Die Überstimmung der Zahlen repräsentiert eindrucksvoll, dass dieKlondetektoren zuverlässige und reproduzierbare Ergebnisse liefern.

Es wurde Code-Klone in Ctp, Lqi, Dhv und Dip in TinyOS 2.x, MintRoute, Route,Drain und MultiHopLQI in TinyOS 1.x gefunden. Betriebssystemübergreifende Code-Klone gibt es jedoch nicht. Dieses Ergebnis bestätigt genau die Vermutung im Abschnitt2.1.2.1.

Nach der Definition vom Ähnlichkeitsgrad sind die Protokollpaare Dip-Dhv mit (15,16%,23,64%) und Route-MintRoute mit (42,93%, 31,05%) besonders ähnlich. Sie werden de-shalb in dem folgenden Abschnitt auf der Datei-Ebene näher betrachtet.

4.2.3. Verteilung der Klone in den Dateien

In diesem Abschnitt werden die Protokolle, die nach der Definition vom Ähnlichkeitsgradin Abschnitt 4.2.2 besonders ähnlich sind, auf der Datei-Ebene näher betrachtet.

4.2.3.1. MintRoute, Route

MintRoute und Route umfassen alle 19 Klonklassen in der Kategorie Multihop. DasProtokoll MultiHopLQI tritt zwar nur in den Klonklassen 16 bis 19 auf, wird aber indiesem Abschnitt trotzdem mit berücksichtigt, da die betroffene Datei im MultiHopLQImit einem Super-Klon (einem 1-zu-1 kopierten Modul) mit Route und MintRoute inVerbindung steht.

Die Verteilung von Klonen in der Datei-Ebene werden in der Tabelle 4.7 mit SLOCDatei,SLOCKlone, KlonanteilimDatei, KlonanteilimP rokoll, SLOCP rookoll, SLOCKlone undKloneanteilP rotokoll dargestellt. Dabei ist SLOCDatei das SLOC einer Datei, SLOCKlone

das SLOC der in dieser Datei enthaltenen Code-Klone, Klonanteilin_Datei der Anteilvon Code-Klonen in dieser Datei, Klonanteilim_P rokoll der Anteil der Code-Klone in

53

4.2 Auswertung

dem Protokoll, SLOCP rotokoll das SLOC eines Protokolls, SLOCKlone die Summe derSLOCDatei in diesem Protokoll und KloneanteilP rotokoll der Anteil von Code-Klonen imProtokoll, berechnet aus SLOCKlone/SLOCP rotokoll.

Route umfasst 1050 SLOC in 4 Dateien, wovon werden 30,67% von Code-Klonen gedecktwerden. 52,80% der Code-Klone befinden sich in der Datei MultiHopLEPSM.nc (dasModul MultiHopLEPSM), 45,65% in Datei MultiHopEngineM.nc (das Modul Multi-HopEngineM), wobei die Datei MultiHopEngineM.nc zu 100% geklont ist.

MintRoute umfasst 750 SLOC in 2 Dateien, wovon 43,47% von Klonen gedeckt werden.54,91% der Klone im MintRoute befinden sich in der Datei MultiHopWMEWMA.nc(das Modul MultiHopWMEWMA), 49,05% in Datei MultiHopEngineM.nc (das Mod-ul MultiHopEngineM). Wobei die Datei MultiHopWMEWMA.nc eine 1-zu-1 Kopie dergleichnamigen Datei im Route ist.

MultiHopLQI umfasst 469 SLOC in 2 Dateien, von denen 6,82% von Klonen gedecktwerden. Dabei befinden sich die Klone alle in der Datei MultiHopEngieM.nc und korre-spondieren mit Fragmenten in der gleichnamigen Datei in Route und MintRoute, jedochnur zu 15,84%.

MintRoute und Route verwenden also dasselbe MultiHopEngineM Modul. Das ModulMultiHopWMEWMA im MintRoute und das Modul MultiHopLEPSM sind sehr ähn-lich. Die Code-Klone zwischen den beiden machen 36,88% vom MultiHopLEPSM und29,68% vom MultiHopWMEWMA aus.

4.2.3.2. Dip und Dhv

In der Kategorie Dissemination konnten nur Klone in Dhv und Dip entdeckt werden.Anders als bei Route und MintRoute sind hier die Klone in mehreren Dateien verteilt.Daher wird die Verteilung in der Tabelle 4.8 anders dargestellt. Die 12 Klonklassen wer-den in 12 Spalten dargestellt, die SLOCD, SLOCK und der Klonanteilin_D sind jeweilsgleichbedeutend wie SLOCDatei, SLOCKlone und Klonanteilin_Datei in der Tabelle 4.7.

Die Klonklassen bestehen jeweils aus einem Klonpaar, also 2 Code-Klonen. Das Vorkom-

54

4.2 Auswertung

Protokoll Datei SLOCDatei SLOCKlone Klonanteilin_Datei Klonanteilim_P rotokollRoute MultiHopLEPSM 461 170 36,88% 52,80%

MultiHopEngineM 147 147 100,00% 45,65%MultiHopRouteM 405 5 1,23% 1,55%MultiHopRouteSelect 37 0 0,00% 0,00%

SLOCP rotokoll 1050SLOCKlone 322KloneanteilP rotokoll 30,67%

Protokoll Datei SLOCDatei SLOCKlone Klonanteilin_Datei Klonanteilim_P rotokollMintRoute MultiHopWMEWMA 603 179 29,68% 54,91%

MultiHopEngineM 147 147 100,00% 45,09%


Protokoll Datei SLOCDatei SLOCKlone Klonanteilin_Datei Klonanteilim_P rotokollMultiHopLQI MultiHopLQI 267 0 0,00% 0,00%

MultiHopEngineM 202 32 15,84% 100,00%


Tabelle 4.7.: Klonanteil auf der Datei-Ebene in Route, MintRote und MultiHopLQI. Die Dateien habendie gemeinsame Endung ".nc"

Klonklasse SLOCK SLOCD Klonanteilim_PProtokoll Datei 1 2 3 4 5 6 7 8 9 10 11 12

Dhv AMDhvP 8 8 6 22 110 20,00%DhvDataP 13 13 88 14,77%DhvHSumP 0 66 0,00%DhvLogicP 0 255 0,00%DhvSummaryP 0 51 0,00%DhvTrickleMilliP 9 6 6 21 54 38,89%DhvVBitP 0 157 0,00%DhvVectorP 16 16 106 15,09%DhvVersionP 60 23 16 99 225 44,00%DisseminatorP 42 42 42 100,00%

Dip AMDipP 8 8 5 21 60 35,00%DipDataP 13 13 84 15,48%DipLogicP 8 8 239 3,35%DipSummaryP 29 29 218 13,30%DipTrickleMilliP 9 6 6 21 54 38,89%DipVectorP 18 18 111 16,22%DipVersionP 7 15 22 76 28,95%DisseminatorP 42 42 42 100,00%

SLOCKlonklasse 84 75 52 34 31 26 18 16 16 12 12 11

Tabelle 4.8.: Klonanteil auf der Datei-Ebene in Dhv und Dip. Die Dateien haben die gemeinsame En-dung ".nc".

55

4.3 Beurteilung der Klondetektoren

men eines Klons in einer Datei wird mit dem SLOC des Klons dargestellt. Eine Ausnahmestellt die Klonklasse 2 dar, dessen Klonmuster in DhvVectorP 7 Male vorgekommen ist,daher werden die SLOC der Klone im Feld DhvVectorP-2 aufsummiert.

Die Dateien DisseminatorP.nc bzw. die Module DisseminatorP (Klonklasse 1) im Dhvund Dip sind bis auf Kommentare und Bezeichner identisch (Typ 2). CCFinder konntedie zwei Dateien komplett als Klonpaar identifizieren, Deckard konnte alle Funktionendie der Suchkriterien entsprechen, jeweils als eine Klonklasse identifizieren. Das Dip-TrickleMilliP Modul und DhvTrickleMilliP sind auch bis auf Kommentare und Bezeich-ner identisch, konnte jedoch von keinem der drei Klondetektoren komplett als Klonpaaridentifiziert werden (nur 38,89% erkannt).

Es ist in der Tabelle auch noch eine Codewanderung zu beobachten. Die gefundeneKlone befinden sich meistens als Klonpaar in namentlich ähnlichen Dateien, die sehrwahrscheinlich auch funktionell ähnlich sind, z.B. die Klonklasse 4 in Dateien DhvVec-torP und DipVectorP, oder die Klonklasse 5 in DhvVersionP und DipVersionP. Aberdie Klonklasse 3, bestehend aus 2 Implementationen der Funktion computeHash() alsTyp-3-Klon, verteilt sich in DhvVersionP und DipSummaryP, statt in DhvVersionP undDipVersionP oder in DhvSummaryP und DipSummaryP. Es könnte auf interne Um-strukturierungen1 des Quellcodes hindeuten.

4.3. Beurteilung der Klondetektoren

Aufgrund der Transformation des Quellcodes konnten viele Metriken, die von den Klon-detektoren erzeugt wurden, nicht für die Auswertung verwendet werden, wie die Klon-typen und LOC. Dennoch konnten die Klondetektoren hinsichtlich Qualität (False-Positive, Relevanz ) der Klonkandidation verglichen werden2. Das Ergebnis3 werden

1Es könnte mehrere Umstrukturierungen gegeben haben, nur diese eine konnte durch Klonerkennungfestgestellt werden.

2Da es keine ausreichenden Testergebnisse von Ccdiml gibt, wird Ccdiml hierbei nicht gesondertberücksichtigt.

3Die Zahlen in den Abbildungen sind nicht mit den Zahlen in Abschnitt 4.2.1 vergleichbar, denn dortwurden die Klonklassen bereits zusammengefasst.

56


durch die Abbildung 4.1 und 4.4 dargestellt.

Abbildung 4.1.: Ergebnisqualität für CCFinder mit C-Code. Jede Säule stellt die gesamte Menge der vonCCFinder gefundenen Klonkondidaten dar. Der rote Bereich stellt die False-Positivendar, der darunter liegende türkise Bereich zwar Klone, die aber nicht für diese Arbeitrelevant sind, der grüne Bereich die relevanten Klone.

Die Abbildung 4.1 zeigt genau das Verhalten von CCFinder, was mit dem ParametersetMCL-MTKS: 30-10 erwartet wurde, keine False-Positiven und ein niedriger Anteil vonuninteressanten Klonen. Die Abbildung 4.4 zeigt, dass Deckard hingegen einen hohenAnteil an False-Positiven liefert. Es liegt vermutlich daran, dass Deckard die Strukturdes AST mit Vektoren im euklidischen Raum approximiert. Es erhöht dadurch zwardas Abstraktionsniveau der zu vergleichenden Informationen, was die Anzahl gefunden-er Klone erhöht, erhöht aber auch die False-Positiven.

Von den 39 relevanten Klonen, die CCFinder gefunden hat, konnte Deckard zwei nichtwieder finden. Anderseits ergänzt Deckard das Ergebnis von CCFinder mit zusätzlichenTyp-3-Klonen, und konnte dabei mehr Funktionen komplett als Klon identifizieren.CCFinder tendiert dazu, mehrere Kleine Funktionen (Häufig nur ein return um denRückgabewert einer Funktionsaufruf zurückzugeben.) zusammen zufügen um die An-

57


Abbildung 4.2.: Ergebnisqualität für Deckard mit C-Code. Jede Säule stellt die gesamte Menge der vonCCFinder gefundenen Klonkondidaten dar. Der rote Bereich stellt die False-Positivendar, der darunter liegende türkise Bereich zwar Klone, die aber nicht für diese Arbeitrelevant sind, der grüne Bereich die relevanten Klone.

58


forderungen, die durch das Parameterset gestellt werden, zu erfüllen. Dadurch gefundeneKlone sind aber für diese Arbeit nicht von Bedeutung.

59


4.3.0.3. Ein Beispiel aus dem Resultat

Um einen Eindruck über die gefundenen Klonen und die Leistungsfähigkeit der Klonde-tektoren zu repräsentieren, wird hier die Klonklasse 4 aus der Kategorie Disseminationgezeigt. Diese Klonklasse umfasst ein Klonpaar mit 17 SLOC in Typ 3. In diesem Klon-paar hat sowohl Umbenennungen der Bezeichnern als auch Hinzufügen von Statementsstattgefunden. Die Funktion erfüllen zwar nicht genau dieselben Funktionalität, weisenjedoch dieselbe Logik auf.

CCFinder konnte die for-Loops als Klon identifizieren4, Deckard konnte die komplettenFunktionen als Klon identifizieren. CCFinder tendiert dazu, mehrere Kleine Funktionen(Häufig nur ein return um den Rückgabewert einer Funktionsaufruf zurückzugeben.)zusammen zufügen um die Anforderungen, die durch das Parameterset gestellt werden,zu erfüllen. Dadurch gefundene Klone sind aber für diese Arbeit nicht von Bedeutung.

4Durch Transformation von nesC in C, sind die Debug Funktionen entfernt worden, daher konnteCCFinder die for-Loop erkennen. In einem Test mit CCFinder und nesC Datei, konnte CCFind-er jedoch nur die Zeilen 21-24 in DhvVectorP.nc und die Zeilen 14-17 in DipVectorP.nc als Klonerkennen.

60


Abbildung 4.3.: Definition für Event VectorReceive.receive aus DhvVectorP.nc

Abbildung 4.4.: Definition für Event VectorReceive.receive aus DipVectorP.nc

61

5. Zusammenfassung und Ausblick

In dieser Arbeit konnte gezeigt werden, dass zwischen manchen der untersuchten WSN-Routing-Protokolle eine signifikante Menge von dupliziertem Code existiert, sowohl als1:1-Kopien als auch als modifizierte Version. Durch die Anwendung der Klonerkennungs-Techniken konnten die Code-Klone in systematischer Weise entdeckt, lokalisiert undklassifiziert werden. Die Ergebnisse erfüllen zum Teil sehr gut die Erwartungen, und dasangewandte Verfahren konnte zuverlässige und reproduzierbare Ergebnisse liefern.

Dadurch ist ein Entwickler in der Lage einen schnellen Überblick über die Verteilung desduplizierten Codes in mehreren Routing-Protokollen zu gewinnen und die gemeinsamenoder ähnlichen Funktionalitäten in den Protokollen festzustellen. Die gemeinsamen Funk-tionalitäten oder Logiken könnten dann eventuell abstrahiert und modularisiert werden,sodass ein Routingprotokoll allein durch den Austausch von Modulen über verschiedeneFunktionalitäten verfügen kann.

Aufgrund der speziellen Programmiersprache nesC, womit die meisten untersuchtenProtokolle geschrieben sind, mussten während dieser Arbeit noch einige wichtige Vor-bereitungsschritte getroffen werden um effektiver Werkzeuge verwenden zu können unddadurch einen akkurateren Resultat zu bekommen. Dadurch sind aber einige von denKlondetektoren gelieferte sinnvolle Metriken, z.B. LOC und Klontypen, nicht mehr di-rekt verwertbar.

Es wurde bereits auf einen bekannten Typ 4 Klon in den untersuchten Routing-Protokollenhingewiesen, welcher mit den angewandten Klonerkennungstechniken nicht entdeckt wer-den konnte, aber für die Entwickler von großem Interesse ist. Um solche Klone, derenGemeinsamkeiten nur noch auf der semantischen Ebene zu erkennen sind, eventuellentdecken zu können, müssen Klondetektoren eingesetzt werden, welche leider zumZeitpunkt dieser Arbeit nicht verfügbar sind. Bei Verfügbarkeit solch eines Klondetek-

62

tors, kann eine vertiefte Untersuchung auf semantisch ähnliche Funktionen unter derWiederverwendung des in dieser Arbeit angewandten Verfahrens durchgeführt werden.

63

A. Detaillierte Ergebnisse für dasParametertuning derKlondetektoren

A.1. CCFinder Parameterset Tuning

Parameterset 15 – 5LEN TKS TYPE POP Relevant

15 8 2-k 315 6 2-k 216 6 2-k 217 5 2-k 217 6 2-k 219 13 1 519 13 2-k 219 9 2-k 221 10 2-k 2 y21 6 2-k 223 6 fp24 12 2-k 225 10 2-k 4 y25 10 2-k 225 10 2-k 326 7 2-k 327 6 fp30 9 fp33 16 2-k 335 13 2-k 2 y35 13 2-k 4 y41 18 2-k 4 y41 9 fp45 14 1 2 y65 16 2-k 276 11 2-k 2 y81 23 2-k 2 y

Tabelle A.1.: CCFinder Parameterset Tuning Testergebnis 15-5

64

A.1 CCFinder Parameterset Tuning

Parameterset 20-10LEN TKS TYPE POP Relevant

35 13 2-k 6 y35 13 2-k 6 y81 23 2-k 2 y25 10 2-k 4 y76 11 2-k 2 y33 16 2-k 365 16 2-k 219 13 2-k 241 18 2-k 2 y21 10 2-k 245 14 1 2 y24 12 2-k 2 y25 10 2-k 525 10 2-k 5



35 13 2-k 6 y35 13 2-k 6 y81 23 2-k 2 y76 11 2-k 2 y33 16 2-k 365 16 2-k 241 18 2-k 2 y45 14 1 2 y



81 23 2-k 2 y65 16 2-k 2 y


65

A.2 Ccdiml Parameterset Tuning

A.2. Ccdiml Parameterset Tuning

Parameterset 5-2Klonpaar Type ist Klon relevant KlonklasseAMDhvP.nc 107 112 DhvDataP.nc 80 87 3 0AMDhvP.nc 107 112 DhvHSumP.nc 59 70 3 0AMDhvP.nc 107 112 DhvSummaryP.nc 59 65 3 0DhvDataP.nc 80 87 DhvHSumP.nc 59 70 3 1 0DhvDataP.nc 60 65 DhvSummaryP.nc 44 48 3 0DhvDataP.nc 80 87 DhvSummaryP.nc 59 65 3 1 0DhvDataP.nc 61 66 DhvVBitP.nc 75 80 3 1 0DhvDataP.nc 61 65 DhvVectorP.nc 51 56 3 0DhvHSumP.nc 40 49 DhvSummaryP.nc 45 53 2-k 1 1 1DhvHSumP.nc 59 70 DhvSummaryP.nc 59 65 3 1 0DhvHSumP.nc 39 44 DhvVBitP.nc 74 79 2-k 1 0DhvHSumP.nc 43 49 DhvVBitP.nc 80 85 3 1 0DhvHSumP.nc 39 44 DhvVectorP.nc 50 57 3 1 0DhvLogicP.nc 70 74 DhvLogicP.nc 97 101 2-k 1 1 2DhvLogicP.nc 82 86 DhvLogicP.nc 109 113 2-k 1 1 3DhvLogicP.nc 236 240 DhvLogicP.nc 257 262 3 1 0DhvSummaryP.nc 45 49 DhvVBitP.nc 75 79 2-k 1 0DhvSummaryP.nc 48 53 DhvVBitP.nc 80 85 3 1 0DhvSummaryP.nc 45 49 DhvVectorP.nc 51 57 3 1 0DhvVBitP.nc 53 64 DhvVBitP.nc 144 154 3 1 1 4DhvVBitP.nc 56 64 DhvVBitP.nc 145 154 1 1 1 4DhvVBitP.nc 91 96 DhvVBitP.nc 173 178 2-k 1 1 5DhvVBitP.nc 74 79 DhvVectorP.nc 50 57 3 1 0DhvVBitP.nc 156 160 DhvVectorP.nc 128 134 3 1 0DhvVersionP.nc 37 44 DhvVersionP.nc 47 54 2-k 1 1 6DhvVersionP.nc 37 44 DhvVersionP.nc 57 64 2-k 1 1 6DhvVersionP.nc 38 44 DhvVersionP.nc 48 54 1 1 1 6DhvVersionP.nc 38 44 DhvVersionP.nc 58 64 1 1 1 6DhvVersionP.nc 47 54 DhvVersionP.nc 57 64 2-k 1 1 6DhvVersionP.nc 48 54 DhvVersionP.nc 58 64 1 1 1 6DhvVersionP.nc 68 74 DhvVersionP.nc 86 93 3 1 1 7DhvVersionP.nc 68 74 DhvVersionP.nc 128 135 3 1 1 7DhvVersionP.nc 68 74 DhvVersionP.nc 148 155 3 1 1 7DhvVersionP.nc 68 72 DhvVersionP.nc 203 208 3 0DhvVersionP.nc 86 94 DhvVersionP.nc 128 136 2-k 1 1 7DhvVersionP.nc 86 94 DhvVersionP.nc 148 156 2-k 1 1 7DhvVersionP.nc 86 92 DhvVersionP.nc 242 246 2 0DhvVersionP.nc 96 102 DhvVersionP.nc 109 115 2-k 1 1 8DhvVersionP.nc 96 103 DhvVersionP.nc 159 166 2-k 1 1 8DhvVersionP.nc 109 115 DhvVersionP.nc 159 165 2-k 1 1 8DhvVersionP.nc 119 125 DhvVersionP.nc 185 191 2-k 1 1 7DhvVersionP.nc 128 136 DhvVersionP.nc 148 156 2-k 1 1 7DhvVersionP.nc 128 134 DhvVersionP.nc 242 246 2-k 1 1 7DhvVersionP.nc 148 154 DhvVersionP.nc 242 246 2-k 1 1 7DhvVersionP.nc 215 219 DhvVersionP.nc 270 276 3 0

Tabelle A.5.: Ccdiml Parameterset Tuning Testergebnis 5-2

66

A.2 Ccdiml Parameterset Tuning

Parameterset 6-2Klonpaar Type ist Klon relevant KlonklasseAMDhvP.nc 107 112 DhvDataP.nc 80 87 3 0AMDhvP.nc 107 112 DhvHSumP.nc 59 70 3 0AMDhvP.nc 107 112 DhvSummaryP.nc 59 65 3 0DhvDataP.nc 80 87 DhvHSumP.nc 59 70 3 1 0DhvDataP.nc 80 87 DhvSummaryP.nc 59 65 3 1 0DhvDataP.nc 61 66 DhvVBitP.nc 75 80 3 1 0DhvHSumP.nc 40 49 DhvSummaryP.nc 45 53 2-k 1 1 1DhvHSumP.nc 59 70 DhvSummaryP.nc 59 65 3 1 0DhvHSumP.nc 39 44 DhvVBitP.nc 74 79 2-k 1 0DhvHSumP.nc 43 49 DhvVBitP.nc 80 85 3 1 0DhvHSumP.nc 39 44 DhvVectorP.nc 50 57 3 1 0DhvSummaryP.nc 48 53 DhvVBitP.nc 80 85 3 1 0DhvVBitP.nc 53 64 DhvVBitP.nc 144 154 3 1 1 4DhvVBitP.nc 56 64 DhvVBitP.nc 145 154 1 1 1 4DhvVBitP.nc 91 96 DhvVBitP.nc 173 178 2-k 1 1 5DhvVBitP.nc 74 79 DhvVectorP.nc 50 57 3 1 0DhvVersionP.nc 37 44 DhvVersionP.nc 47 54 2-k 1 1 6DhvVersionP.nc 37 44 DhvVersionP.nc 57 64 2-k 1 1 6DhvVersionP.nc 38 44 DhvVersionP.nc 48 54 1 1 1 6DhvVersionP.nc 38 44 DhvVersionP.nc 58 64 1 1 1 6DhvVersionP.nc 47 54 DhvVersionP.nc 57 64 2-k 1 1 6DhvVersionP.nc 48 54 DhvVersionP.nc 58 64 1 1 1 6DhvVersionP.nc 68 74 DhvVersionP.nc 86 93 3 1 1 7DhvVersionP.nc 68 74 DhvVersionP.nc 128 135 3 1 1 7DhvVersionP.nc 68 74 DhvVersionP.nc 148 155 3 1 1 7DhvVersionP.nc 86 94 DhvVersionP.nc 128 136 2-k 1 1 7DhvVersionP.nc 86 94 DhvVersionP.nc 148 156 2-k 1 1 7DhvVersionP.nc 96 102 DhvVersionP.nc 109 115 2-k 1 1 8DhvVersionP.nc 96 103 DhvVersionP.nc 159 166 2-k 1 1 8DhvVersionP.nc 109 115 DhvVersionP.nc 159 165 2-k 1 1 8DhvVersionP.nc 119 125 DhvVersionP.nc 185 191 2-k 1 1 7DhvVersionP.nc 128 136 DhvVersionP.nc 148 156 2-k 1 1 7


Klonpaar Type ist Klon relevant KlonklasseAMDhvP.nc 107 112 DhvDataP.nc 80 87 3 0AMDhvP.nc 107 112 DhvHSumP.nc 59 70 3 0AMDhvP.nc 107 112 DhvSummaryP.nc 59 65 3 0DhvDataP.nc 80 87 DhvHSumP.nc 59 70 3 1 0DhvDataP.nc 80 87 DhvSummaryP.nc 59 65 3 1 0DhvHSumP.nc 40 49 DhvSummaryP.nc 45 53 2-k 1 1 1DhvHSumP.nc 59 70 DhvSummaryP.nc 59 65 3 1 0DhvHSumP.nc 39 44 DhvVBitP.nc 74 79 2-k 1 0DhvLogicP.nc 70 74 DhvLogicP.nc 97 101 2-k 1 1 2DhvLogicP.nc 82 86 DhvLogicP.nc 109 113 2-k 1 1 3DhvLogicP.nc 236 240 DhvLogicP.nc 257 262 3 1 0DhvSummaryP.nc 45 49 DhvVBitP.nc 75 79 2-k 1 0DhvVBitP.nc 56 64 DhvVBitP.nc 145 154 1 1 1 4DhvVBitP.nc 91 96 DhvVBitP.nc 173 178 2-k 1 1 5DhvVersionP.nc 37 44 DhvVersionP.nc 47 54 2-k 1 1 6DhvVersionP.nc 37 44 DhvVersionP.nc 57 64 2-k 1 1 6DhvVersionP.nc 38 44 DhvVersionP.nc 48 54 1 1 1 6DhvVersionP.nc 38 44 DhvVersionP.nc 58 64 1 1 1 6DhvVersionP.nc 47 54 DhvVersionP.nc 57 64 2-k 1 1 6DhvVersionP.nc 48 54 DhvVersionP.nc 58 64 1 1 1 6DhvVersionP.nc 68 74 DhvVersionP.nc 86 93 3 1 1 6DhvVersionP.nc 68 74 DhvVersionP.nc 128 135 3 1 1 6DhvVersionP.nc 68 74 DhvVersionP.nc 148 155 3 1 1 7DhvVersionP.nc 68 72 DhvVersionP.nc 203 208 3 0DhvVersionP.nc 86 94 DhvVersionP.nc 128 136 2-k 1 1 7DhvVersionP.nc 86 94 DhvVersionP.nc 148 156 2-k 1 1 7DhvVersionP.nc 86 92 DhvVersionP.nc 242 246 2 0DhvVersionP.nc 96 102 DhvVersionP.nc 109 115 2-k 1 1 8DhvVersionP.nc 96 103 DhvVersionP.nc 159 166 2-k 1 1 8DhvVersionP.nc 109 115 DhvVersionP.nc 159 165 2-k 1 1 8DhvVersionP.nc 119 125 DhvVersionP.nc 185 191 2-k 1 1 7DhvVersionP.nc 128 136 DhvVersionP.nc 148 156 2-k 1 1 7DhvVersionP.nc 128 134 DhvVersionP.nc 242 246 2-k 1 1 7DhvVersionP.nc 148 154 DhvVersionP.nc 242 246 2-k 1 1DhvVersionP.nc 215 219 DhvVersionP.nc 270 276 3 0


67

A.3 Deckard Parameterset Tuning

A.3. Deckard Parameterset Tuning

Parameterset 20-0,90Klonklasse Datei Start End ist Klon Typ relevant

DhvHSumP.c 82 11 nDhvVectorP.c 65 17

1 DhvVersionP.c 100 12 y 2-k yDhvVersionP.c 186 11DhvVersionP.c 77 13DhvVersionP.c 163 13

2 DhvVBitP.c 55 8 y 1 yDhvVBitP.c 152 9

3 DhvVersionP.c 255 8 y 3, 2-k yDhvVersionP.c 43 8DhvVersionP.c 54 8DhvVersionP.c 65 9DhvVersionP.c 127 9DhvVersionP.c 139 9DhvVersionP.c 151 9

DhvHSumP.c 85 8 nDhvVBitP.c 213 5

4 DhvVBitP.c 89 8 y 2-k yDhvVBitP.c 181 5

5 DhvLogicP.c 59 6 y 3, 2-k yDhvLogicP.c 68 6DhvLogicP.c 77 6DhvLogicP.c 101 6DhvLogicP.c 110 6DhvLogicP.c 119 6

6 DisseminatorP.c 85 6 y 2-k yDisseminatorP.c 116 6DisseminatorP.c 109 4

DhvLogicP.c 165 6 nDhvLogicP.c 185 6

Tabelle A.8.: Deckard Parameterset Tuning Testergebnis 20-0,90

68

A.3 Deckard Parameterset Tuning

Parameterset 20-0,98Klonklasse Datei Start End ist Klon Typ Relevant

1 DhvVersionP.c 186 11 y 2-k yDhvVersionP.c 77 13DhvVersionP.c 163 13

3 DhvVersionP.c 43 8 y 2-k yDhvVersionP.c 54 8DhvVersionP.c 65 9DhvVersionP.c 127 9DhvVersionP.c 139 9DhvVersionP.c 151 9


DhvVBitP.c 89 8 nDhvVBitP.c 181 5

5 DhvLogicP.c 59 6 y 2-k yDhvLogicP.c 68 6DhvLogicP.c 101 6DhvLogicP.c 110 6

5, Typ3 in 20-90 DhvLogicP.c 77 6 y 2-k yDhvLogicP.c 119 6

6 DisseminatorP.c 85 6 y 2-k yDisseminatorP.c 116 6

Teil von 1 DhvVersionP.c 106 3 y 2-k nDhvVersionP.c 191 3DhvVersionP.c 82 4DhvVersionP.c 168 4



DhvVectorP.c 63 19 nDhvVectorP.c 145 16

DhvHSumP.c 82 11 nDhvVectorP.c 65 17

DhvVersionP.c 335 13 nDhvVersionP.c 221 16


DhvLogicP.c 290 11 nDhvVectorP.c 105 10



DhvVersionP.c 115 7 nDhvVersionP.c 199 6


69

A.4 Protokolle, deren Dateien und SLOCs



2 DhvVBitP.c 55 8 y 1DhvVBitP.c 152 9



A.4. Protokolle, deren Dateien und SLOCs

Dissemination: 2252

Dhv 1154 Dip 884 Drip 214

AMDhvP.nc 110 AMDipP.nc 60 DisseminationEngineImplP.nc 156DhvDataP.nc 88 DipDataP.nc 84 DisseminatorP.nc 58DhvHSumP.nc 66 DipLogicP.nc 239 DisseminationEngineP.nc 27DhvLogicP.nc 255 DipSummaryP.nc 218DhvSummaryP.nc 51 DipTrickleMilliP.nc 54DhvTrickleMilliP.nc 54 DipVectorP.nc 111DhvVBitP.nc 157 DipVersionP.nc 76DhvVectorP.nc 106 DisseminatorP.nc 42DhvVersionP.nc 225DisseminatorP.nc 42

Tabelle A.12.: Kategorie Dissemination: Protokolle ,untersuchte Dateien und SLOC

Collection: 3028

Ctp 1044 Drain 1053 Lqi 931

CtpForwardingEngineP.nc 528 DrainGroupManagerM.nc 48 LqiForwardingEngineP.nc 403CtpRoutingEngineP.nc 516 DrainLinkEstM.nc 435 LqiRoutingEngineP.nc 302

DrainM.nc 337 MultiHopEngineM.nc 226GrouperM.nc 72GroupManagerM.nc 161

Tabelle A.13.: Kategorie Collection: Protokolle ,untersuchte Dateien und SLOC

70

A.4 Protokolle, deren Dateien und SLOCs

Mesh: 2513

Drain 1053 Drip 241

DrainLinkEstM.nc 435 DisseminationEngineImplP.nc 156DrainM.nc 337 DisseminatorP.nc 58GroupManagerM.nc 161 DisseminationEngineP.nc 27GrouperM.nc 72DrainGroupManagerM.nc 48

MintRoute 750 MultiHopLQI 469

MultiHopWMEWMA.nc 603 MultiHopLQI.nc 267MultiHopEngineM.nc 147 MultiHopEngineM.nc 202

Tabelle A.14.: Kategorie Mesh: Protokolle ,untersuchte Dateien und SLOC

Tree: 2255

Ctp 1044 WSNS 403 Zigbee 808

CtpForwardingEngineP.nc 528 runMyalgo.c 403 NWKP.nc 808CtpRoutingEngineP.nc 516

Tabelle A.15.: Kategorie Tree: Protokolle ,untersuchte Dateien und SLOC

Multihop: 8255

Blip 2544 RPL Sensorscope 523

IPRoutingP.nc 986 rpl-dag.c 492 NeighborhoodC.nc 201IPDispatchP.nc 652 rpl-icmp6.c 476 NetworkMultiHopP.nc 147ICMPResponderP.nc 304 rpl-timers.c 135 NetworkBSP.nc 142UdpP.nc 151 rpl.c 126 NextHopRandomP.nc 33TcpP.nc 123 rpl-of-etx.c 87TrackFlowsP.nc 109 rpl-of0.c 60IPExtensionP.nc 105IPAddressP.nc 65ResourceSendP.nc 49

Route 1050 MintRoute 750 MultiHopLQI 469

MultiHopLEPSM.nc 461 MultiHopWMEWMA.nc 603 MultiHopLQI.nc 267MultiHopRouteM.nc 405 MultiHopEngineM.nc 147 MultiHopEngineM.nc 202MultiHopEngineM.nc 147MultiHopRouteSelect.nc 37

TinyAODV 999 uAODV 544

AODV_Core.nc 668 uaodv.c 461AODV_PacketForwarder.nc 331 uaodv-rt.c 83

Tabelle A.16.: Kategorie Multihop: Protokolle ,untersuchte Dateien und SLOC

71

Literaturverzeichnis

[1] Chanchal K. Roy, James R. Cordy, Rainer Koschke B, Comparison andevaluation of code clone detection techniques and tools: A qualitative ap-proach. Science of Computer Programming Volume 74, Issue 7, Pages470-495, 1 May 2009.

[2] Toshihiro Kamiya, Shinji Kusumoto, and Katsuro Inoue, CCFinder: Amulti-linguistic token-based code clone detection system for large scalesource code. IEEE Transactions on Software Engineering, 28(6):654–670,2002.

[3] Richard Wettel, Automated Detection Of Code Duplication Clusters,Diploma Thesis, Faculty of Automatics and Computer Science of thePolitehnica University of Timisoara, Timioara, June 2004.

[4] J. Johnson, Identifying Redundancy in Source Code Using Fingerprints,Proceedings of the 1993 Conference of the Centre for Advanced Studieson Collaborative Research, CASCON 1993, pp. 171–183, 1993.

[5] S. Ducasse, M. Rieger and S. Demeyer, A Language Independent Ap-proach for Detecting Duplicated Code, Proceedings of the 15th Interna-tional Conference on Software Maintenance, ICSM 1999, pp. 109-118,1999.

[6] BAKER , B RENDA S., A program for identifying duplicated code. Com-puter Science and Statistics 24: Proceedings of the 24th Symposium onthe Interface, s.49–57, 1992.

[7] BAKER , B RENDA S., On Finding Duplication and Near-Duplication

72


in Large Software Systems. W ILLS , L., P. N EWCOMB and E.C HIKOFSKY: Second Working Conference on Reverse Engineering,86–95, Los Alamitos, California, 1995. IEEE Computer Society Press.

[8] T. Kamiya, S. Kusumoto and K. Inoue, CCFinder: A MultilinguisticToken-Based Code Clone Detection System for Large Scale Source Code,IEEE Transactions on Software Engineering, 28(7):654-670, 2002.

[9] I. Baxter, A. Yahin, L. Moura and M. Anna, Clone Detection Using Ab-stract Syntax Trees, in: Proceedings of the 14th International Conferenceon Software Maintenance, ICSM 1998, pp. 368-377, 1998.

[10] L. Jiang, G. Misherghi, Z. Su and S. Glondu, DECKARD: Scalable andAccurate Tree-based Detection of Code Clones, in: Proceedings of the29th International Conference on Software Engineering, ICSE 2007, pp.96-105, 2007.

[11] National Instrument, "Was ist ein Wireless-Sensornetzwerk?"(http://zone.ni.com/devzone/cda/tut/p/id/9638)last accessed Juli 2010.

[12] MICS, EPFL, SensorScope, Homepage(http://sensorscope.epfl.ch/index.php/Network_Code) last accessedJuli 2010

[13] Hemant Mohapatra, Sensor network simulator,http://sourceforge.net/projects/wsn-simulator/files/ last modified13/04/2005

[14] TinyOS Documentation Wiki, Nesc-internals,(http://docs.tinyos.net/index.php/Nesc-internals) last accessed Juli2010

[15] Yu-Seung Ma, Duk-Kyun Woo, Domain Analysis of Device Drivers UsingCode Clone Detection Method, ETRI Journal, vol.30, no.3, June 2008,pp.394-402.

73


[16] TinyOS Projekt Homepage, (http://www.tinyos.net/) last accessed Juli2010

[17] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo,D. Gay, J. Hill, M. Welsh, E. Brewer, D. Culler, TinyOS: An OperatingSystem for Sensor Networks, Ambient Intelligence In Ambient Intelli-gence (2005), pp. 115-148.

[18] B.W. Kernighan and D.M. Ritchie, The C Programming Language, Sec-ond Edition. Prentice Hall, 1988.

[19] David Gay, Philip Levis, David Culler, Eric Brewer, nesC 1.1 LanguageReference Manual , May 2003

[20] R. Koschke, R. Falke and P. Frenzel, Clone Detection Using AbstractSyntax Suffix Trees, Proceedings of the 13th Working Conference onReverse Engineering, WCRE 2006, pp. 253-262 (2006).

[21] Project Bauhaus. URL http://www.bauhaus-stuttgart.de/bauhaus/,Last accessed Juli 2010, Bauhaus Version 5.6.6.

[22] Semiautomatische Entfernung des duplizierten Codes, Yidong Liu,Diplomarbeit, Universität Stuttgart Fakultät Informatik, Elektrotechnikund Informationstechnik, 11.07.2004

[23] A. Gionis, P. Indyk, and R. Motwani, Similarity search inhigh dimensionsvia hashing, VLDB, 1999.

[24] Lingxiao Jiang, Ghassan Misherghi, Zhendong Su, Stephane Glondu,Deckard: Scalable and Accurate Tree-based Detection of Code Clones,Presentation, wwwcsif.cs.ucdavis.edu/ jiangl/papers/icse07slides.pdf,last accessed 07.08.2010

[25] The Contiki Operation System, Version 2.4 (16 February 2010),http://www.sics.se/contiki, last accessed Juli 2010

[26] J. N. AL-Karaki, A. E. Kamal, “Routing Techniques in Wireless Sensor

74


Networks: A Survey”, IEEE Wireless Communications, Volume 11, Issue6, Dec. 2004 Page(s):6 - 28

[27] Heterogeneous Sensor Routing (HSN) Stack,http://tinyos.cvs.sourceforge.net/tinyos/tinyos-1.x/contrib/hsn/ lastaccessed Juli 2010

[28] A. Woo, T. Tong, and D. Culler, Taming the underlying challenges ofreliable multi-hop routing in sensor networks, SenSys ’03: Proceedings ofthe 1st international conference on Embedded networked sensor systems,pages 14–27, Los Angeles, California, USA, 2003. ACM Press.

[29] Multihop Routing, http://webs.cs.berkeley.edu/tos/tinyos-1.x/doc/multihop/multihop_routing.html last accessed Juli 2010

[30] Siebe Datema, A Case Study of Wireless Sensor Network Attacks,Master’s Thesis in Computer Science, Delft University of Technology,September 22th, 2005

[31] Ioannis Krontiris, Thanassis Giannetsos, Tassos Dimitriou, Launching aSinkhole Attack in Wireless Sensor Networks; the Intruder Side, AthensInformation Technology, 19002 Peania, Athens, Greece

[32] Drain, a collection routing layer for TinyOS,http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-1.x/tos/lib/Drain/ last accessed Juli 2010

[33] Dissemination of Small Values, http://www.tinyos.net/tinyos-2.x/doc/txt/tep118.txt last accessed Juli 2010

[34] Drip, http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x/tos/lib/net/drip/

[35] Dip, http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x/tos/lib/net/dip/

[36] Thanh Dang, Nirupama Bulusu, Wu-chi Feng, Seungweon Park, DHV: A

75


Code Consistency Maintenance Protocol for Multi-hop Wireless SensorNetworks, Lecture Notes in Computer Science, 2009, Volume 5432/2009,327-342, DOI: 10.1007/978-3-642-00224-3_21

[37] Philip Levis, Neil Patel, David Culler, Scott Shenker, Trickle: A Self-Regulating Algorithm for Code Propagation and Maintenance in WirelessSensor Networks, Proceedings of the 1st conference on Symposium onNetworked Systems Design and Implementation - Volume 1, San Fran-cisco, California, 2004

[38] Dymo, http://www.ianchak.com/dymo/ last accessed Juli 2010

[39] Tymo, An implementation of the DYMO protocol on TinyOS,http://tymo.sourceforge.net/implementation last accessed Juli 2010

[40] Blip Tutorial - TinyOS Documentation Wiki,http://docs.tinyos.net/index.php/BLIP_Tutorial, last accessed Juli2010

[41] Collection TinyOS 2.x, http://www.tinyos.net/tinyos-2.1.0/doc/html/tep119.html, last accessed Juli 2010

[42] André CUNHA, Mário ALVES, Anis KOUBÂA, Technical Report, Im-plementation of the ZigBee Network Layer with Cluster-tree Support, TR-070510, Version: 1.0, 26-05-2007

[43] Frank Oldewurtel, Björn Grönvall, RUNES/D1.8/PU/v1.1Contiki development report, http://www.sics.se/b̃g/RUNES-D1.8_v1.1_Contiki.pdf 07/09/2007.

[44] Nicolas Tsiftes, Joakim Eriksson, Niclas Finne, Fredrik Österlind, JoelHöglund, Adam Dunkels. A Framework for Low-Power IPv6 RoutingSimulation, Experimentation, and Evaluation. ACM SIGCOMM 2010,demo session, New Delhi, India, August 2010.

[45] W. Heinzelman, A. Chandrakasan, H. Balakrishnan, Energy-EfficientCommunication Protocol for Wireless Microsensor Networks, Proceed-

76


ings of the 33rd Hawaii International Conference on System Sciences(HICSS ’00), January 2000.

[46] T. Schmid, H. Dubois-Ferrière, and M. Vetterli. SensorScope: Experi-ences with a Wireless Building Monitoring Sensor Network. In Workshopon Real-World Wireless Sensor Networks (REALWSN’05), 2005.

[47] Shah Bhatti, James Carlson, Hui Dai, Jing Deng, Jeff Rose, AnmolSheth, Brian Shucker, Charles Gruenwald, Adam Torgerson, RichardHan, MANTIS OS: An Embedded Multithreaded Operating System forWireless Micro Sensor Platforms, ACMKluwer Mobile Networks & Ap-plications (MONET) Journal, Special Issue on Wireless Sensor Networks,August 2005.

[48] Chih-Chieh Han, Ram Kumar Rengaswamy, Roy Shea, Eddie Kohler andMani Srivastava. SOS: A dynamic operating system for sensor networks,Proceedings of the Third International Conference on Mobile Systems,Applications, And Services (Mobisys), 2005.

[49] Nano-RK: A Wireless Sensor Networking Real-Time Operating System,Homepage (http://www.nanork.org/)

77

Erklärung gemäß Bachelor-Prüfungsordnung

Hiermit versichere ich, die vorliegende Bachelorarbeit selbständig verfasst und nur dieangegebenen Quellen und Hilfsmittel verwendet zu haben. Mit einer Ausleihe der Arbeiterkläre ich mich einverstanden

Hamburg, den 20. September 2010Yi Tang

Documents

Erkennung von Quellkodeduplikaten in WSN ...moeller/publist-sts-pw-and-m/...Erkennung von Quellkodeduplikaten in WSN-Routingprotokollen mittels Klondetektoren Bachelorarbeit vorgelegt