Implementierung eines Eclipse-Plugins zum automatisierten Testen von Refaktorisierungswerkzeugen

Transkript

1 Fernuniversität in Hagen Fakultät für Mathematik und Informatik Lehrgebiet Programmiersysteme Prof. Dr. Friedrich Steimann Abschlussarbeit im Studiengang Master of Computer Science Implementierung eines Eclipse-Plugins zum automatisierten Testen von Refaktorisierungswerkzeugen Osama El Hosami Matrikelnummer: August 2010 Betreuer: Christian Kollee

2 Hiermit versichere ich, dass ich die vorliegende Arbeit selbstständig und nur mit den angegebenen Hilfsmitteln angefertigt habe. Wörtlich oder inhaltlich übernommene Literaturquellen wurden besonders gekennzeichnet. Osama El Hosami Minden, August

3 Inhaltsangabe Durch Refaktorisierungen werden bedeutungserhaltende Änderungen an Programmen durchgeführt. Diese verfolgen das Ziel, dem schleichenden Prozess der Verschlechterung der Softwarequalität (Softwarefäulnis) entgegen zu wirken und sind damit bei der Wartung von Programmen, zumindest auf lange Sicht, unverzichtbar. [26] Heutige Entwicklungsumgebungen, wie z.b. Eclipse, NetBeans oder Visual-Studio, bieten Werkzeugunterstützung zur automatisierten Anwendung von Refaktorisierungen an. Viele der existierenden Refaktorisierungswerkzeuge bleiben jedoch hinter den gestellten Erwartungen, so dass diese nicht korrekt Arbeiten und Fehler einführen [25]. Die Fehler, die dabei durch Anwendung von Refaktorisierungswerkzeugen in ein Programm eingeführt werden, reichen von Übersetzungsfehlern bis hin zu Verhaltensänderungen, die bestenfalls im Zuge des Testens aufgedeckt werden oder gänzlich unentdeckt bleiben. Um jedoch die Qualität von Refaktorisierungswerkzeugen nachhaltig zu verbessern, bietet sich, wie für andere Programme auch, das Testen an. Mit dem Refactoring Tool Tester aus dieser Arbeit steht eine Referenzimplementierung für das automatisierte Testen von Java-Refaktorisierungswerkzeugen in Eclipse zur Verfügung. 3

4 Inhaltsverzeichnis Abbildungsverzeichnis 7 Tabellenverzeichnis 9 1 Einleitung Motivation Problemstellung Aufbau der Arbeit Begrisdenitionen 15 3 Lösungsansatz Vorgehensweise Architektur Ablauf von Tests Steuerung und Überwachung von Aktoren Testfälle für Refaktorisierungswerkzeuge Grundlagen und Hilfsmittel Implementierung Organisation Plugins Abhängigkeiten Pakete Framework Struktur Modell Konguration Erweiterung Benutzerinterface Diskussion Interpretation und Bewertung Vergleich mit verwandten Arbeiten Schlussbetrachtungen Zusammenfassung und Fazit

5 Inhaltsverzeichnis 6.2 Ausblick Literaturverzeichnis 67 Literaturverzeichnis 67 A Paketstruktur 70 B Schnellstartanleitung 73 B.1 Installation und Deinstallation B.1.1 Auslieferung B.1.2 Voraussetzungen B.1.3 Installation B.1.4 Deinstallation B.2 Erzeugen von Testprojekten B.3 Erzeugen von Kongurationen B.3.1 Bereitstellung von Probanden-Projekten B.3.2 Launch-Konguration B.4 Debuggen C CD Inhaltsverzeichnis 91 5

6 Abkürzungsverzeichnis API AWT COM CORBA CSV CVS DbC DCOM DSL GC HTML IDE JDT JVM MVC OSGi PDE PDF POJO RCP RTT SDK SVN SWT UI UML URI VCM XML Application Programming Interface Abstract Window Toolkit Component Object Model Common Object Request Broker Architecture Comma-Separated Values Concurrent Version System Design by Contract Distributed Component Object Model Domain-specic language Garbage Collector Hypertext Markup Language integrierte Entwicklungsumgebung Java Development Tools virtuelle Java-Maschine Model-View-Controller Open Services Gateway Initiative Plugin Development Environment Portable Document Format Plain Old Java Object Rich-Client-Plattform Refactoring Tool Tester Software-Development-Kit Subversion Standard Widget Toolkit User Interface Unied Modeling Language Uniform Resource Identier Versions- und Kongurationsmanagement-System Extensible Markup Language 6

7 Abbildungsverzeichnis 1.1 Beispielklasse zur Anwendung der Rename-Refaktorisierung Beispielklasse zur Darstellung von Übersetzungsfehlern bei fehlerhafter Rename-Refaktorisierung Beispielklasse zur Darstellung von Verhaltensänderungen bei fehlerhafter Rename-Refaktorisierung JUnit-Testfall zur Aufdeckung von Verhaltensänderungen in der Beispielklasse Architektur des Refactoring Tool Testers [25] Erweiterte Architektur des Refactoring Tool Testers Schema der Testkonguration Basiskomponenten des Refactoring Tool Testers Koordinations-Komponenten des RTT Schema einer Testklasse mit Testfällen für Refaktorisierungswerkzeuge Erweiterungsbeziehungen zwischen Plugins [34] Dienstverzeichnis des OSGi-Framework [29] Dienstkomponenten-Laufzeitumgebung [17] Schichten des Refactoring Tool Testers Übersicht der RTT-Core Komponentenstruktur Übersicht der RTT Komponentenstruktur Übersicht der RTT Modellelemente Schnittstellen des RTT Modells Verarbeitungszustände eines Modellelements Schnittstellen und Klassen der Testkonguration Schematische Struktur einer XML-Testkonguration Schematische Struktur einer Komponentenbeschreibung zur Realisierung einer RTT-Erweiterung Erweiterte schematische Struktur einer Komponentenbeschreibung zur Realisierung einer RTT-Erweiterung Ausschnitt einer Plugin-Manifest-Datei mit Komponentenbeschreibungen Schnittstellen zur Realisierung von Aktoren Hilfsklassen zur Realisierung von Aktoren Schnittstelle zur Anbindung eines Repositories Schnittstellen und Klassen zur Realisierung einer Modell-Beobachter-Komponente

8 Abbildungsverzeichnis 4.16 Schnittstelle zur Realisierung einer Aktion für die Testergebnisansicht Testergebnisansicht Filter der Testergebnisansicht B.1 Software Updates B.2 Installation und Feature-Auswahl B.3 Installation abschlieÿen B.4 About Eclipse und Installationsdetails B.5 Installationsdetails B.6 Deinstallation B.7 Deinstallation abschlieÿen B.8 Erzeugen eines Projektes B.9 Erzeugen eines Plugin-Projektes B.10 Einstellungen eines Plugin-Projektes B.11 Inhalt eines Plugin-Projektes B.12 Abhängigkeit auf RTT Core Plugin B.13 Test-Klasse erzeugen B.14 Informationen der Test-Klasse festlegen B.15 Import Aktion B.16 Import eines bestehenden Projektes B.17 Import aus einem Projekt-Archiv B.18 Projekt mit Repository verknüpfen B.19 SVN Connector Auswahl B.20 Repository Informationen festlegen B.21 Initialer Commit B.22 Launch-Konguration önen B.23 Testkonguration erzeugen B.24 Auswahl des Testprojektes B.25 Aktor-Konguration eines Probanden B.26 Hinzufügen von Probanden zur Konguration

9 Tabellenverzeichnis 3.1 Kongurationselemente der Testkonguration Annotationen für deklarative Testadapter Verarbeitungsergebnisse im RTT Modell Verarbeitungszuständen im RTT Modell Kardinalitäten für Referenzen einer Komponenten-Beschreibung Gegenüberstellung der Werkzeuge ASTGen, SafeRefactor und RTT A.2 Übersicht der RTT Paketstruktur Teil A.4 Übersicht der RTT Paketstruktur Teil A.6 Übersicht der RTT Paketstruktur Teil

10 1 Einleitung 1.1 Motivation Durch Refaktorisierungen werden bedeutungserhaltende Änderungen an Programmen durchgeführt. Diese verfolgen das Ziel, dem schleichenden Prozess der Verschlechterung der Softwarequalität (Softwarefäulnis) entgegen zu wirken und sind damit bei der Wartung von Programmen, zumindest auf lange Sicht, unverzichtbar. [26] Refaktorisierungen liegen in einer verbalen Spezikation (u.a. [5]) vor, die es Software-Entwicklern ermöglicht diese manuell durchzuführen. Gerade die manuelle Durchführung von Refaktorisierungen birgt Gefahren, so dass bei nicht Beachtung notwendiger Vor- bzw. Nachbedingungen das beobachtbare Verhalten von Programmen verändert wird und damit das Ziel einer bedeutungserhaltenden Änderung verfehlt ist. Erschwerend kommt hinzu, dass notwendige Vor- bzw. Nachbedingungen für viele Refaktorisierungen oftmals unvollständig speziziert oder Aufgrund der Menge von betroenen Sprachkonstrukten bei der Anwendung nicht manuell zu Überblicken sind. Aus dem zweiten Grund bieten heutige Entwicklungsumgebungen, wie z.b. Eclipse, NetBeans oder Visual-Studio, Werkzeugunterstützung zur automatisierten Anwendung von Refaktorisierungen an. Dennoch bleiben viele der existierenden Refaktorisierungswerkzeuge hinter den gestellten Erwartungen, so dass diese nicht korrekt Arbeiten und Fehler einführen [25]. Die Fehler, die dabei durch Anwendung von Refaktorisierungswerkzeugen in ein Programm eingeführt werden, reichen von Übersetzungsfehlern bis hin zu Verhaltensänderungen, die bestenfalls im Zuge des Testens aufgedeckt werden oder gänzlich unentdeckt bleiben. Um die Qualität von Refaktorisierungswerkzeugen zu verbessern, bietet sich, wie für andere Programme auch, das Testen an. Durch das Testen kann zwar nicht die Korrektheit und damit die Abwesenheit von Fehlern bewiesen werden, es können aber Fehler mit vertretbarem Aufwand aufgedeckt werden. Für das Testen von Refaktorisierungswerkzeugen werden Beispielprogramme benötigt, die das zu refaktorisierende Sprachkonstrukt enthalten und dieses in einem Kontext einbetten der mögliche Fehler des Refaktorisierungswerkzeugs aufdeckt. Stellvertretend für einen solchen Kontext kommen Regressionstests in Frage das Fehlschlagen eines Testfalls kennzeichnet dann, die durch die Refaktorisierung eingebrachte Verhaltensänderung und damit gleichzeitig den Fehler in der Refaktorisierung. Die syntaktische Überprüfung eines Beispielprogramms erfolgt durch den Übersetzer. Die Regressionstests übernehmen im Anschluss die semantische Überprüfung und stellen damit das unveränderte beobachtbare Verhalten sicher. Die manuelle Anwendung der beschriebenen Testschritte ist relativ aufwendig und fehleranfällig. Insbesondere die Generierung repräsentativer Beispielprogramme bzw. notwendiger Regressionstests stellen die Tester vor eine schwierige Aufgabe, 10

11 1 Einleitung so dass viele verbleibende Fehler die Folge sind. Abhilfe kann das automatisierte Testen von Refaktorisierungswerkzeugen schaen. [25] Die Idee des automatisierten Testens von Refaktorisierungswerkzeugen ist nicht neu. Es existieren Testwerkzeuge [2][24] zum automatisierten Testen von Refaktorisierungswerkzeugen, welche bereits erfolgreich Fehler in den Eclipse- und NetBeans-eigenen Refaktorisierungswerkzeugen nachgewiesen haben. Eine Abgrenzung der vorliegenden Arbeit zu diesen erfolgt im Unterkapitel 5.2. Des Weiteren ist parallel zu dieser Arbeit eine Untersuchung der Eclipse-eigenen Refaktorisierungen mit Hilfe des, in dieser Arbeit implementierten, Refactoring Tool Testers [9] gestartet worden. 1.2 Problemstellung Wie bereits im Unterkapitel 1.1 angedeutet sind viele Refaktorisierungswerkzeuge fehlerhaft und erfüllen damit nicht die an Programmierwerkzeuge gestellten Qualitätsansprüche. Dies liegt vor allem daran, dass die spezizierten Refaktorisierungen Lücken aufweisen, wie z.b. die unvollständige Beschreibung anzuwendender Schritte oder notwendiger Vorund Nachbedingungen. Diese Versäumnisse sind nur bedingt auf die Nachlässigkeit der Autoren zurückzuführen fällt es doch schwer selbst einfache Refaktorisierung vollständig zu überblicken. Gerade die, aus der Kombination und Variation einer Refaktorisierung entstehende, Menge aller möglicherweise betroenen Sprachkonstrukte übersteigt in vielen Fällen ein überschaubares Maÿ und sprengt damit den Rahmen einer solchen Beschreibung. Somit macht die korrekte und vollständige Spezikation von Refaktorisierungen erst im Rahmen der Entwicklung eines dazugehörigen Refaktorisierungswerkzeugs Sinn und kann durch Einsatz eines Testwerkzeugs dokumentiert werden.[25] Im Folgenden wird, zum Zweck der Problemdarstellung, an einem Beispiel ein mögliches Fehlschlagen der Rename-Refaktorisierung angeführt. Dabei werden die Arten von eingebrachten Fehlern aufgezeigt und dargestellt wie diese aufgedeckt werden können. Beispiel Entscheidet sich ein Benutzer, im Beispielprogramm aus Abbildung 1.1, innerhalb der Methode add(int value) einen neuen Bezeichner für die Variable value zu wählen, kann mit Hilfe des Rename-Refaktorisierungswerkzeugs die notwendigen Code- Änderungen vorgenommen werden. Werden dabei, wie beispielsweise in Abbildung 1.2 gezeigt, nur die Codezeilen 06 und 07 verändert, die notwendigen Anpassung an der Methodensignatur hingegen vergessen, führt dies zu Syntaxfehlern, die durch den Übersetzer gemeldet werden. Sehr viel unangenehmer stellen sich Verhaltensänderungen dar, die durch ein Refaktorisierungswerkzeug eingebracht werden. Diese bleiben durch den Übersetzer unentdeckt und werden bestenfalls im Zuge des Testens aufgedeckt oder bleiben gänzlich unentdeckt. Zu einer Verhaltensänderung, des Beispielprogramms aus Abbildung 1.1, kann es kommen, wenn in den Nachbedingungen des Refaktorisierungswerkzeugs vergessen wurde auf schon existierende Programmelemente mit gleichen Bezeichnern zu 11

12 1 Einleitung 1 c l a s s Counter { 2 3 p r i v a t e i n t _value = 0 ; 4 5 p u b l i c void add ( i n t value ) { 6 _value = _value + value ; 7 System. out. p r i n t l n ( value ) ; 8 } 9 10 p u b l i c i n t get ( ) { 11 r e t u r n _value ; 12 } 13 } Abbildung 1.1: Beispielklasse zur Anwendung der Rename-Refaktorisierung 1 c l a s s Counter { 2 3 p r i v a t e i n t _value = 0 ; 4 5 p u b l i c void add ( i n t value ) { 6 _value = _value + renamedvalue ; 7 System. out. p r i n t l n ( renamedvalue ) ; 8 } 9 10 p u b l i c i n t get ( ) { 11 r e t u r n _value ; 12 } 13 } Abbildung 1.2: Beispielklasse zur Darstellung von Übersetzungsfehlern bei fehlerhafter Rename-Refaktorisierung 12

13 1 Einleitung 1 c l a s s Counter { 2 3 p r i v a t e i n t _value = 0 ; 4 5 p u b l i c void add ( i n t _value ) { 6 _value = _value + _value ; 7 System. out. p r i n t l n ( _value ) ; 8 } 9 10 p u b l i c i n t get ( ) { 11 r e t u r n _value ; 12 } 13 } Abbildung 1.3: Beispielklasse zur Darstellung von Verhaltensänderungen bei fehlerhafter Rename-Refaktorisierung 1 p u b l i c c l a s s TestCounter { 2 4 p u b l i c void testadd ( ) { 5 Counter counter = new Counter ( ) ; 6 counter. add ( ) ; 7 a s s e r t E q u a l s (815, counter. get ( ) ) ; 8 } Abbildung 1.4: JUnit-Testfall zur Aufdeckung von Verhaltensänderungen in der Beispielklasse prüfen. Wird durch den Benutzer des Refaktorisierungswerkzeugs die Umbenennung des Bezeichners value, innerhalb der Methode add(int value), auf _value gefordert, sollte ein korrekt implementiertes Rename-Refaktorisierungswerkzeug dies ablehnen. Wird die Änderung hingegen, wie in Abbildung 1.3 dargestellt, durchgeführt, kommt es zu der bereits erwähnten Verhaltensänderung. Durch Anwendung eines eventuell vorhandenen Regressionstests à la JUnit kann die eingebrachte Verhaltensänderung aufgedeckt werden, wie in Abbildung 1.4 dargestellt. Dieser würde nach eingebrachter Änderung fehlschlagen. Aufgabenstellung Das Hauptaugenmerk dieser Arbeit liegt in der Entwicklung eines Eclipse-Plugins zum automatisierten Testen von Refaktorisierungswerkzeugen. Dabei soll ein zu testendes Refaktorisierungswerkzeug auf mögliche Programmelemente eines Probanden-Projektes angewendet werden und durch Anwendung vorhandener Testfälle geprüft werden, ob das Programm immer noch dieselbe Bedeutung hat. 13

14 1 Einleitung 1.3 Aufbau der Arbeit Nachdem im ersten Kapitel auf die Motivation der Arbeit eingegangen und Anhand von Beispielen die Problemstellung erörtert wurde, folgt im Kapitel 2 die Denition von in dieser Arbeit verwendeten Begrien. Das Kapitel 3 stellt die Vorgehensweise, Architektur und Konzepte der Lösung vor. Des Weiteren werden die notwendigen Grundlagen zum Verständnis der Implementierung vermittelt. Im Kapitel 4 wird die auf dem Lösungsansatz basierende Umsetzung beschrieben. Insbesondere wird in diesem Kapitel auf die Organisation, Struktur und die bereitgestellten Möglichkeiten zur Erweiterung der Implementierung eingegangen. Daneben werden die Mittel zur Analyse vor Fehlern präsentiert. Im folgenden Kapitel 5 werden die Ergebnisse der Arbeit diskutiert und mit verwandten Arbeiten verglichen. Das Kapitel 6 schlieÿt die Arbeit mit einer Zusammenfassung und einem Fazit, gefolgt von einem Ausblick, ab. 14

15 2 Begrisdenitionen Refaktorisierung Refaktorisierungen sind Modikationen am Programmcode mit dem Ziel der Verbesserung der Softwarestruktur, ohne deren Bedeutung zu ändern. Sie wirken damit dem schleichenden Prozess der Verschlechterung der Softwarequalität (Softwarefäulnis) entgegen und sind bei der Wartung von Programmen, zumindest auf lange Sicht, unverzichtbar. Eine Refaktorisierung ist fehlerhaft, wenn der Code nach Durchführung ein anderes Verhalten aufweist. Die Bedeutungserhaltung des Codes ist somit die zentrale Anforderung an Refaktorisierungen. [26] Flower deniert eine Refaktorisierung als Abfolge von Schritten, die die interne Struktur eines Programms modizieren, ohne das beobachtbare Verhalten zu verändern [5]. A series of small steps, each of which changes the program's internal structure without changing its external behavior [5]. Unterschieden werden Refaktorisierung von Refaktorisierungswerkzeugen; eine Refaktorisierung bezeichnet das Muster, also die Vorgehensweise, das Refaktorisierungswerkzeug hingegen ein Programm, das die Refaktorisierung automatisiert vornehmen kann. [25] Refaktorisierungswerkzeug Refaktorisierungswerkzeug sind Programme, die eine Refaktorisierung automatisiert vornehmen können. Für die automatisierte Anwendung einer Refaktorisierung wählt ein Benutzer, neben dem Refaktorisierungswerkzeug, die zu refaktorisierenden Programmelemente bzw. Parameter aus. Nach Überprüfung aller Vorund Nachbedingungen wendet das Refaktorisierungswerkzeug die Refaktorisierung mit den festgelegten Parametern an und transformiert alle im Programm betroenen Sprachkonstrukte. Für den Fall, dass mindestens eine Vor- bzw. Nachbedingungen nicht erfüllt ist, wird die Refaktorisierung nicht ausgeführt und entsprechende Fehlermeldungen ausgegeben. In den Vorbedingungen werden die angegebenen Eingabeparameter auf ihre Korrektheit überprüft; die Nachbedingungen überprüfen, nach Berechnung der betroenen Sprachkonstrukte, ob die geplanten Änderungen gültig und damit bedeutungserhaltenden sind. Insbesondere werden Nachbedingungen nicht nach Ausführung einer Refaktorisierung validiert, sondern nach Berechnung der betroenen Sprachkonstrukte. Modultest Der Begri Modultest beschreibt die kleinste eigenständig zu testende Programmeinheit das Modul. In der objektorientierten Programmierung sind diese Programmeinheiten Methoden, Klassen oder im Extremfall ganze Pakete [26]. Zu jeder Programmeinheit wird ein Modultest speziziert, der einen Testfall umsetzt. Da Klassen, in 15

16 2 Begrisdenitionen der objektorientierten Programmierung, in der Regel aus einem Geecht von Objekten bestehen, kommen zur Isolation von zu testenden Einheiten Mock-Objekte zum Einsatz. Diese Stellvertreter ahmen dann das Verhalten des realen Objektes nach und stellen damit die Isolation sicher. [20] Für das automatisierte Testen von Programmen stehen, für Modultests, Testwerkzeuge bereit. Bekannte Vertreter sind JUnit, NUnit oder CPPUnit, die zur Familie der xunit-frameworks 1 gehören. Zu den typisch im Modultest eingesetzten Testverfahren zählt der Regressionstest [6]. Des Weiteren existieren diverse Testwerkzeuge zur Analyse der Testabdeckung, wie z.b. Cobertura, Jester oder Quilt in Verbindung mit JUnit. Regressionstest Der Regressionstest gehört zu den dynamischen Testverfahren und setzt damit die Ausführbarkeit des zu testenden Programms voraus. Gemeinsam haben alle dynamischen Testverfahren, dass das zu testende Programm zusammen mit den festgelegten systematischen Eingabedaten (Testfällen) ausgeführt wird. Für jeden Testfall werden neben den Eingabedaten auch die erwarteten Ausgabedaten angegeben. Die durch einen Testlauf erzeugten Ausgabedaten werden mit den jeweils erwarteten Daten verglichen. Bei Abweichungen liegt ein Fehler vor. Für das Testverfahren, des Regressionstest, werden alle oder eine Teilmenge von existierenden Testfällen, nach Durchführung von Modikationen, wiederholt, um Folgefehler oder Seiteneekte in bereits getesteten Programmteilen auszuschlieÿen. Solche Modikationen entstehen in der Regel durch Pege, Änderung und Korrektur von Programmen. Aufgrund des Wiederholungscharakters und der Häugkeit dieser Wiederholungen werden Regressionstests sinnvollerweise automatisiert durchgeführt. [14][6] Proband Im Kontext des Refactoring Tool Testers stellen Probanden Eingabe-Projekte dar. Dabei sind Probanden autonome Beispielprogramme, die zu refaktorisierenden Sprachkonstrukte enthalten und diese in einen Kontext einbetten, der mögliche Fehler des Refaktorisierungswerkzeugs aufdeckt. Analog zu der medizinischen Verwendung des Begris Proband, kann dieser, im technischen Kontext des automatisierten Testens von Refaktorisierungen, als Versuchsperson (engl. test subject) bzw. -kandidat aufgefasst werden, an dem eine Refaktorisierung erprobt wird. [25] Orakel Zum Nachweisen von Fehlern in Refaktorisierungswerkzeugen kommt das sogenannte Back-to-Back-Testverfahren zum Einsatz [25]. Dabei werden die Ausgaben von verschiedenen Versionen von Programmen miteinander verglichen. Für den Anwendungsfall des Refactoring Tool Testers, werden die Ausgaben des Original-Programms, mit denen nach Refaktorisierung, verglichen. Da das Back-to-Back-Testverfahren zu den dynamischen Testverfahren gehört, ist die Ausführbarkeit des Probanden, vor und nach Refaktorisierung, vorausgesetzt. [14] Der beschriebenen Problemstellung widmen sich Orakel im Kontext des Refactoring Tool Tester. Das Testwerkzeug stellt durch Anfragen an Orakel 1 Der vorangestellte Buchstabe x kennzeichnet dabei die eingesetzte Programmiersprache. 16

17 2 Begrisdenitionen den Zustand (übersetzbar bzw. unverändertes beobachtbares Verhalten) eines Probanden fest. Repository Repositories sind im Wesentlichen Archive (beispielsweise CVS oder SVN), in denen Projekte verwaltet werden [25]. Für den Refactoring Tool Testers werden vorzugsweise Probanden hinterlegt und zum Zwecken des automatisierten Testens von Refaktorisierungswerkzeugen entnommen. Durch die Repositories ist gewährleistet, dass eine zuvor erzeugte Testkonstellation wiederhergestellt werden kann. Komponentensoftware Unter dem Begri der komponentenorientierten bzw. komponentenbasierten Softwareentwicklung versteht man die Entwicklung von Softwaresystemen durch Zusammensetzen von bereits vorgefertigten, getesteten und wiederverwendbaren Softwarekomponenten (engl. Software Components) [28]. Die Motivation hinter der komponentenorientierten Softwareentwicklung liegt darin, dass die Erstellung komplexer Anwendungen zu niedrigeren Kosten bei hoher Qualität und innerhalb geringere Entwicklungszeiten ermöglicht werden soll. Gewährleistet wird dies vor allem dadurch, dass die Software aus bereits vorgefertigten und vollständig getesteten Komponenten zusammengesetzt wird. Zwar brachte bereits die Einführung der objektorientierten Softwareentwicklung groÿe Fortschritte in der Wiederverwendung von Software, konnte aber letztendlich die Wiederverwendung in der Masse von Anwendungen nur eingeschränkt fossieren. Heute bildet die objektorientierte Softwareentwicklung die Grundlage für die komponentenorientierte Softwareentwicklung (engl. component-based development) und damit für Komponentensoftware, die letztendlich das Produkt der komponentenorientierte Softwareentwicklung ist [7]. Komponentenmodell Damit Komponenten die wichtigsten Anforderungen, wie z.b. Interoperabilität, Plattform- und Hersteller-Unabhängigkeit oder Wiederverwendbarkeit, erfüllen, müssen diese nach Standards entwickelt werden. Im Kontext komponentenorientierten Entwicklung werden diese Standards durch Komponentenmodelle festgelegt. Ein Komponentenmodell gibt die Architektur, zu diesem Modell, konformer Komponenten vor. Die Denition eines Komponentenmodells gliedert sich in der Festlegung folgender drei Teilbereiche [12]: Festlegung der Semantik welche Bedeutung haben Komponenten und wie stellen sie sich im Modell dar, Festlegung der Syntax wie werden sie repräsentiert und erzeugt, Festlegung der Komposition wie werden Komponenten verbunden bzw. zusammengefügt. Damit Komponenten auch ausgeführt werden können, muss eine Komponentenmodell- Implementierung bereitgestellt werden. Diese Ausführungsumgebung wird durch Frameworks in Applikationservern, Containern oder auch Plattformen realisiert. Es existieren 17

18 2 Begrisdenitionen eine ganze Reihe von Komponentenmodellen, die eine Teilmenge der notwendigen Anforderungen für Softwarekomponenten denieren, dazu gehören beispielsweise JavaBeans, COM/DCOM, CORBA oder auch OSGi. [11] Framework Ein Framework liefert ein Programmgerüst, also eine wiederverwendbare Schablone, für das Erstellen bestimmter Klassen von Softwaresystemen. Dabei deniert das Framework die Architektur und die erlaubten Kollaborationen zwischen Komponenten. Durch Vervollständigung des Frameworks können konkrete Softwaresysteme ausgebaut werden. Ein Framework deniert insbesondere den Kontrolluss der Anwendung und die Schnittstellen für die konkreten Klassen, die vom Programmierer erstellt und registriert werden müssen. [11] Somit kann ein Framework als Ausführungsumgebung aufgefasst werden, in der die vom Programmierer bereitgestellten Erweiterungen ausgeführt werden (Prinzip inversion of control). Auch für die bereits, im Unterkapitel 2, eingeführten Komponentenmodelle existieren Implementierungen in Form von Frameworks, wie z.b. die OSGi Referenzimplementierung Equinox. 18

19 3 Lösungsansatz 3.1 Vorgehensweise Wie bereits in der Motivation dieser Arbeit eingeleitet, fallen Refaktorisierungswerkzeuge in die Kategorie der Metaprogramme, wie z.b. Übersetzer oder Debugger und weitere Programmierwerkzeuge. Da sich Fehler in Metaprogrammen vor allem in der Ausführung der von ihnen manipulierten Programme zeigen, sind diese Programme besonders schwer zu Debuggen und zu Testen. Insbesondere das Testen von Refaktorisierungswerkzeugen gestaltet sich nicht einfach: Es werden Beispielprogramme benötigt, die das zu refaktorisierende Sprachkonstrukt enthalten und dieses in einen Kontext einbetten, der mögliche Fehler des Refaktorisierungswerkzeugs aufdeckt. Der Lösungsansatz des Refactoring Tool Testers geht daher von der Generierung notwendiger Probanden ab und bedient sich an der Vielzahl verfügbarer quelloener (engl. open-source) Programme. Durch dieses Vorgehen ergeben sich gleich zwei Vorteile: Zum einen handelt es sich bei den Probanden um reale Anwendungen, die eine Vielzahl der von den Anwendern verwendeten Sprachkonstrukten beinhalten und damit repräsentativ sind, zum anderen besitzen viele quelloene Programme eine hohe Testabdeckung (in Form von JUnit-Testfällen), die zur semantischen Prüfung herangezogen werden kann. Aus diesen Gegebenheiten vereinfacht sich das automatisierte Testen von Refaktorisierungswerkzeugen, denn es können die in der integrierten Entwicklungsumgebung vorhandenen Mittel zur Validierung einer Refaktorisierung zu Hilfe genommen werden diese dienen dann dem Testwerkzeug als Orakel. Dem entsprechend übernimmt der Übersetzer die syntaktische Überprüfung eines Probanden. Die Ausführung der Regressionstests übernimmt im Anschluss die semantische Überprüfung und stellt damit das unveränderte beobachtbare Verhalten sicher, das denitionsgemäÿ die Korrektheit einer Refaktorisierung qualiziert. Im Artikel [25] wird der vereinfachte Algorithmus des automatischen Testwerkzeugs vorgestellt, der in der Grundidee mit dem in dieser Arbeit implementierten Refactoring Tool Tester übereinstimmt. Der dort beschriebene Ablauf nutzt die bereits eingeleiteten Sachverhalte in den folgenden Zusammenhängen: Eingabe Beispielprogramme (vorzugsweise quelloene Programme), die die zu refaktorisierenden Sprachkonstrukte enthalten und gut durch Tests abgedeckt sind, werden als Probanden aus einem Repository entnommen. Das Repository dient dabei dem 19

20 3 Lösungsansatz Zweck der Verwaltung von Probanden gemeinsam mit ihren Kongurationsinformationen, wie z.b. die von Testläufen ausgeschlossenen Klassen. Verarbeitung Das Testwerkzeug wendet ein Refaktorisierungswerkzeug, indirekt über einen zuvor bereitgestellten Testadapter, auf allen anwendbaren 1 Programmstellen an und prüft nach Refaktorisierung mittels der o.g. Orakel, ob alle Änderungen bedeutungserhaltend sind. Die Testadapter stellen dabei die Kopplung zwischen Refaktorisierungswerkzeug und Testwerkzeug her und sind dafür verantwortlich notwendige Parameter für die Refaktorisierung festzulegen. Die Bereitstellung von Testadaptern erfolgt über die von Eclipse zur Verfügung gestellten Plugin-Mechanismen, so dass diese Komponenten den Refactoring Tool Tester erweitern. Die zugehörige Status-Meldung, zum Erfolg oder Misserfolg einer Refaktorisierung, wird nach jeder Anwendung eines Refaktorisierungswerkzeugs über das Testwerkzeug erzeugt und kann so angezeigt oder weiterverarbeitet werden. Nach Anwendung einer Refaktorisierung werden im Abschluss jedes Verarbeitungsschritts alle Änderungen, vor Anwendung der nächsten Refaktorisierung, rückgängig gemacht, so dass für jede Refaktorisierung die gleichen Ausgangsbedingungen herrschen. Ausgabe Für den Benutzer des automatischen Testwerkzeugs werden die Status-Meldungen aufbereitet, die im Anschluss aller Testläufe zur Fehleranalyse herangezogen werden können. Insbesondere beinhaltet die Ausgabe die Refaktorisierungsbeschreibung und die dazugehörigen Status-Meldungen der Orakel. Die Refaktorisierungsbeschreibung beinhaltet die notwendigen Informationen zum Refaktorisierungswerkzeug und alle bei der Refaktorisierung verwendete Parameter. Wie angedeutet erfolgt die Durchführung von automatisierten Refaktorisierungen als Batchprozess, der dem klassischen Eingabe-Verarbeitung-Ausgabe-Modell unterliegt. Bevor die Beschreibung des in dieser Arbeit implementierten Refactoring Tool Testers fortgeführt wird, folgt in Abbildung 3.1 zum Zweck der Gegenüberstellung die im Artikel [25] beschriebene Architektur. Wie in Abbildung 3.1 dargestellt, sind das Probanden-Repository und die Orakel Bestandteile des Testwerkzeugs. Die Testadapter, die Probanden und das zu testende Refaktorisierungswerkzeug werden vom Benutzer des Testwerkzeugs vor der Anwendung eines Testlaufs bereitgestellt. Typischerweise können die Probanden nach Bereitstellung unverändert für verschiedene Testläufe wiederverwendet werden. An dem zu testenden Refaktorisierungswerkzeug sind keinerlei Anpassungen notwendig, die Testadapter stellen die notwendige Kopplung zum Testwerkzeug her. Der Aufwand für das Testen eines konkreten Refaktorisierungswerkzeugs beschränkt sich damit auf das Bereitstellen von mindestens einem Testadapter nachdem das Probanden-Repository notwendige Beispielprogramme beinhaltet. Insbesondere müssen Tester in der Regel keine Testfälle für ein Refaktorisierungswerkzeug formulieren, da das Refaktorisierungswerkzeug nur indirekt getestet wird und die Testfälle zur Verizierung einer bedeutungserhaltenden Änderung zu den Projekten der Probanden gehören. Zur Schnittstelle eines Testadapters gehört die Identikation anwendbarer Programmstellen, die vom Testwerkzeug für Refaktorisie- 1 Dies beinhaltet insbesondere die Überprüfung notwendiger Vor- und Nachbedingungen eines Refaktorisierungswerkzeugs. 20

21 3 Lösungsansatz Abbildung 3.1: Architektur des Refactoring Tool Testers [25] rungen angefordert werden. Die Bestimmung der Programmstellen in den Probanden, an denen eine Refaktorisierung ausgeführt werden kann, kann vorzugsweise durch Ablauf des abstrakten Syntaxbaums (AST) herausgeltert werden. Schwieriger gestaltet sich die Auswahl geeigneter Parameter für ein Refaktorisierungswerkzeug, um tatsächlich Fehler aufzudecken. Insbesondere können für manche Refaktorisierungen nicht alle Kombinationen von Parameterwerten durchprobiert werden, wenn diese potentiell unendlich viele darstellen, wie z.b. bei der Rename-Refaktorisierung [25]. Für diese Art von Refaktorisierungen ist es notwendig Parameter zu wählen, die gezielt Fehler provozieren und damit die Laufzeit von notwendigen Testläufen begrenzen womit die Formulierung eines solchen Testadapters im Extremfall des einen Testfalls gleich kommt [25]. Anforderungen Aus den bereits angeführten Ausführungen sind folgende Anforderungen, an das umgesetzte Testwerkzeug, abgeleitet worden: 1. Testadapter sind die zentralen Koppelglieder zwischen Refaktorisierungswerkzeug und Testwerkzeug und müssen daher in ihrer Formulierung einfach gestaltet sein, um den Implementierungsaufwand für das Testen eines Refaktorisierungswerkzeugs zu minimieren. Insbesondere sollte das Testwerkzeug Tester bei der Umsetzung wiederkehrende Aufgaben (im Hinblick auf Testadapter) unterstützen und ggf. Hilfsklassen bereitstellen, die z.b. das Finden und Filtern von anwendbaren Programmstellen für ein Refaktorisierungswerkzeug erleichtern. 2. Da das Durchprobieren aller Kombinationen von Parameterwerten für einige Refaktorisierungswerkzeuge nicht zielführend ist, ist es notwendig, dass das Testwerkzeug den Tester bei der Auswahl von Parameterwerten unterstützt, die es ihm ermöglichen gezielt Fehler zu provozieren. 3. Probanden-Projekte werden, gemeinsam mit ihren Kongurationsinformationen, in Repositories verwaltet und zum Zweck des Testens von Refaktorisierungen entnommen. Die Verwaltung und Bereitstellung von Testkongurationen für Testläufe sind notwendiger Bestandteil des Testwerkzeugs, so müssen neben den anzuwendenden 21

22 3 Lösungsansatz Testadaptern für ein Refaktorisierungswerkzeug, die zu verwendenden Probanden- Projekte ausgewählt und benötigte Parameter festgehalten werden. Insbesondere muss das Testwerkzeug sicherstellen, dass eine Testkonstellation im Nachhinein reproduzierbar ist. 4. Orakel sind die zentralen Anlaufstellen des Testwerkzeugs und ermöglichen ihm die indirekte Identikation von Fehlern in Refaktorisierungswerkzeugen. Auÿer den beschriebenen Orakeln zur syntaktischen und semantischen Überprüfung von Probanden, die zum Umfang des Testwerkzeugs gehören, sollte der Refactoring Tool Tester um weitere erweitert werden können. 5. Dem Benutzer des Testwerkzeugs sind Mittel zur Analyse von Fehlern bereitzustellen, die ihm die systematische Lokalisierung von Fehlerquellen ermöglichen. Insbesondere ist die Anbindung von automatischen Werkzeugen zur Lokalisierung von Fehlerquellen vorzusehen. 3.2 Architektur Die angeführten Anforderungen, aus dem Unterkapitel 3.1, denieren die Rahmenbedingungen für die Architektur, des in dieser Arbeit implementierten Refactoring Tool Testers. Insbesondere stellt die zweite Anforderung eine Herausforderung dar. Während sich die Auswahl von anwendbaren Programmstellen für ein Refaktorisierungswerkzeug eher einfach gestaltet (diese können durch Ablauf des abstrakten Syntaxbaum eines Probanden herausgeltert werden), stellt sich die Auswahl von Parameterwerten, zum Zweck der gezielten Provokation von Fehlern, als schwierig heraus. Zwar ist die gleiche Vorgehensweise für einfache Anwendungsfälle, wie z.b. für das Rename-Refaktorisierungswerkzeug, möglich, um in Konikt stehende Sprachkonstrukte auszuwählen, aber mit einem zusätzlichen Laufzeit- und Programmieraufwand verbunden. Müssen zudem Beziehung zwischen Programmelementen, z.b. zwischen Klassen oder -Hierarchien, ausgedrückt werden, kann der Aufwand schnell Überhand nehmen. Vergleicht man die Auswahl von anwendbaren Programmstellen mit der Auswahl von Parameterwerten, zum Zweck der gezielten Provokation von Fehlern, stellt man fest, dass beide das Ziel verfolgen eine Menge von Programmstellen zu selektieren. Lediglich die Auswahlkriterien unterscheiden sich. Somit vereinfacht sich die Problemlösung in der Bereitstellung von Mechanismen zur Selektion von Programmstellen in Probanden nach Auswahlkriterien, die durch den Tester eines Refaktorisierungswerkzeugs festzulegen sind. Abfragesprachen bieten die geforderten Eigenschaften und kommen typischerweise in Programm-Analysewerkzeugen zum Einsatz, wie z.b. SemmleCode. Den gleichen Ansatz verfolgt der Refactoring Tool Testers zur Erfüllung der ersten und zweiten Anforderung. Hierzu kann durch Einsatz eines Abfragewerkzeugs eine Formalisierung von Testadaptern erfolgen. Das Testwerkzeug stellt einen Testadapter bereit, der mittels Introspektion Testfälle für Refaktorisierungswerkzeuge anwendet diese Testfälle sind nicht zu verwechseln 22

23 3 Lösungsansatz Abbildung 3.2: Erweiterte Architektur des Refactoring Tool Testers mit denen die zur semantischen Überprüfung angewendet werden und Teil der Probanden Projekte sind. Damit der spezialisierte Testadapter (Abfragewerkzeug-Testadapter) Testfälle identizieren kann, müssen diese gekennzeichnet bzw. annotiert werden. Mit diesen Mitteln entfällt die Notwendigkeit Testadapter zu implementieren, wenn Tester Testfälle, für das automatisierte Testen von Refaktorisierungswerkzeugen, formulieren. Grundsätzlich stehen beide Implementierungsmöglichkeiten zur Verfügung, so dass die Design-Entscheidung dem Tester obliegt. Die bereits angeführten Zusammenhänge werden durch die, in Abbildung 3.2 gezeigte, erweiterte Architektur des Refactoring Tool Testers berücksichtigt. Vergleicht man die gezeigte Architektur, aus Abbildung 3.2, mit der bereits vorgestellten, aus Abbildung 3.1, ist festzustellen, dass diese sich lediglich in der beschriebenen Erweiterung unterscheiden. Zur Erfüllung der dritten Anforderung, aus dem Unterkapitel 3.1, legt der Refactoring Tool Tester eine Testkonguration fest. Diese Testkonguration gliedert sich in der Kon- guration von zu verwendenden Probanden und Aktoren zu den Aktoren zählen Orakel und Testadapter. Die Abbildung 3.3 zeigt die Beziehungen und Elemente innerhalb einer Testkonguration. In erster Linie dient die gezeigte Testkonguration der Reproduzierbarkeit einer Testkonstellation und wird sinnvollerweise zu diesem Zweck in einem Repository hinterlegt. Wie dargestellt werden Probanden in Repositories verwaltet. Innerhalb einer Testkonguration können Probanden verschiedener Repositories angefordert werden. Dafür ist in einer Testkonguration festzuhalten, welchem Repository ein Proband zugehört. Eine weitere notwendige Information kann die Version eines Probanden sein, wenn dieser in einem Proband-Repository verwaltet wird, das mehrere Versionen unterscheidet, wie z.b. ein Versionskontrollsystem. Auch Aktoren besitzen eine Konguration, die beispielsweise angibt welche Ressourcen vom Aktor berücksichtigt bzw. unberücksichtigt bleiben. Die dort angegeben Typen von Ressourcen sind Aktor-spezisch und gehören zu einem der 23

24 3 Lösungsansatz Abbildung 3.3: Schema der Testkonguration zu verwendenden Probanden. Notwendig ist der Ausschluss von Ressourcen beispielsweise für die semantische Orakel-Konguration bei Testfällen (à la JUnit), die in Testsuiten 2 verwaltet sind, um die redundante Ausführen zu vermeiden. Um den wiederkehrenden Kongurationsaufwand für Aktoren, bei der Erzeugung einer neuen Testkonguration, zu vermeiden, kann eine Aktor-Konguration als Standard-Konguration im Probanden hinterlegt werden. Für den Abfragewerkzeug-Testadapter sind weitere Kongurationen notwendig, so unter anderem die anzuwendenden Testfälle für ein Refaktorisierungswerkzeug. Testfälle für Refaktorisierungswerkzeuge werden in einem Testbündel verwaltet, das diese dem Testwerkzeug verfügbar macht. Die Tabelle 3.1 fasst die beschriebenen Bestandteile einer Testkonguration zusammen. 2 Eine Testsuite ist eine Testfall, der aus anderen Testfällen (ggf. auch Suiten) zusammengesetzt wird. 24

25 3 Lösungsansatz Kongurationselement Proband Orakel Testadapter Beschreibung legt ein zu verwendendes Probanden-Projekt fest. Bestandteil der Konguration ist die URI des Projektes, die neben dem Repository das Projekt eindeutig kennzeichnet. legt ein zu verwendendes Orakel fest. Bestandteile der Konguration sind die eindeutige ID des Orakels und ggf. ausgeschlossener Ressourcen in den Probanden-Projekten. legt einen zu verwendenden Testadapter fest. Bestandteile der Konguration ist die eindeutige ID des Testadapters. Des Weiteren sind für den Abfragewerkzeug- Testadapter, die ID des zu verwendenden Testbündels und darin ausgewählter Testfälle festzulegen. Tabelle 3.1: Kongurationselemente der Testkonguration Für die angestrebte Umsetzung in der integrierten Entwicklungsumgebung Eclipse können Testbündel durch Plugins repräsentiert werden. Die Rolle eines Testbündels kann sowohl durch ein separates Plugin als auch durch das Plugin, des zu testenden Refaktorisierungswerkzeugs, übernommen werden. Im Bezug auf die Erweiterbarkeit, des Testwerkzeugs, liegt die Aktor-Konguration in Verantwortung des jeweiligen Aktors, so dass die Struktur für weitere Aktoren um neue Kongurationselemente erweitert werden kann. Die vierte Anforderung, der Erweiterbarkeit des Refactoring Tool Testers, wird explizit durch die integrierte Entwicklungsumgebung (IDE) Eclipse unterstützt. So werden sowohl Orakel als auch Testadapter durch den Eclipse-eigenen Plugin Mechanismus bereitgestellt. Insbesondere übernimmt das unterlagerte Komponenten-Framework (Equinox), für Eclipse, die notwendige Verwaltung von der Bereitstellung über das Aunden bis hin zur Instantiierung von Komponenten. Die Entwickler von Aktoren müssen lediglich Dienstkomponenten im Sinne des OSGi-Komponentenmodell bereitstellen. Die Schnittstellen der o.g. Aktoren deniert das Testwerkzeug. Da Aktoren, als Komponenten, vorzugsweise zustandslos realisiert werden, existiert zu jedem Aktor im System nur eine Instanz. Diese werden durch das Komponenten-Framework geliefert und verwaltet. Ein Vorteil, der sich aus der Zustandslosigkeit von Komponenten ergibt, ist, dass auf Synchronisation verzichtet werden kann, womit die Skalierbarkeit und Wiederverwendbarkeit von Aktoren, auch für andere Werkzeuge, begünstigt wird. Auf der anderen Seite macht dieses Softwaredesign es notwendig, dass alle Informationen zur Ausführung eines Dienstes mit jedem Aufruf übergeben werden. Zur Erfüllung der letzten Anforderung, aus dem Unterkapitel 3.1, verfeinert der Refactoring Tool Testers seine Architektur durch das Model-View-Controller (MVC) Architekturmuster. Die Abbildung 3.4 zeigt die beteiligten Basiskomponenten des Refactoring Tool Testers. Der Anwendungskern übernimmt die Steuerung und Überwachung von Aktoren 25

26 3 Lösungsansatz Abbildung 3.4: Basiskomponenten des Refactoring Tool Testers und damit die Rolle des Controllers. Das Benutzerinterface, der View, wird über Ergebnisse von Testläufen benachrichtigt, die über den Anwendungskern delegiert werden. Die Ergebnisse eines Testlaufs sind Aktor-spezisch und werden über diesen durch entsprechende Modellelemente repräsentiert. Das gesamte Modell ist hierarchisch aufgebaut, so dass alle Informationen von der Sitzung über die Testkonguration bis hin zum Fehlerbild bei Benachrichtigung zur Verfügung stehen. Durch die dargestellte Trennung zwischen Darstellungs-, Verarbeitungs- und Datenhaltungsschicht können auf einfache Weise weitere Analysewerkzeuge angebunden werden. Dazu registrieren sich Analysewerkzeuge, wie beispielsweise das Benutzerinterface, für Benachrichtigungen von Modelländerungen beim Anwendungskern. Die notwendigen Mechanismen für die Registrierung werden, wie bereits bei den Orakel- und Testadapter-Komponenten, durch das Komponenten-Framework geliefert. 3.3 Ablauf von Tests Wie bereits eingeleitet, benötigt der Refactoring Tool Tester zur Anwendung eines automatisierten Tests, neben den Probanden und den Aktoren, eine Testkonguration. Die Bestandteile der Testkonguration sind in der Tabelle 3.1 beschrieben. Aus der Testkonguration bestimmt der Refactoring Tool Tester die zu verwendenden Aktoren und Probanden. Die Aktoren werden dem Refactoring Tool Tester durch das Komponenten- Framework bereitgestellt. Vorbereitend für einen Testlauf werden die festgelegten Probanden durch den Anwendungskern aus ihren Repositories abgerufen. Die so erzeugten Probanden-Projekte bilden gemeinsam mit der Testkonguration den Initialen-Testkontext, 26

27 3 Lösungsansatz der für jeden Aktor instantiiert wird. Nach Instantiierung wird dieser Kontext dem jeweiligen Aktor zur Analyse von Probanden bereitgestellt. Die Analyse bildet damit die Start- bzw. Initialisierungsphase eines Aktors und wird für einen Testlauf einmalig ausgeführt. Welche vorbereitenden Maÿnahmen in der Initialisierungsphase notwendig sind, ist Aktor-spezisch so wird beispielsweise ein Testadapter zu refaktorisierende Programmstellen, das semantische Orakel hingegen anzuwendende Testfälle, Suchen und Filtern. Andere Aktoren könnten auf die Initialisierungsphase auch gänzlich verzichten. Auÿer der beschriebenen Initialisierungsphase unterscheiden Aktoren die Phasen Anwendung und Finalisierung. Die eigentlichen Arbeiten werden vom Aktor in der Anwendungsphase übernommen. Die Finalisierung bildet das Gegenstück zur Initialisierung und wird nach Abschluss eines Testlaufs eingeleitet, um ggf. zu bereinigende Ressourcen aufzuräumen. Da Aktoren, als Komponenten, vorzugsweise zustandslos realisiert werden, können Zwischenergebnisse zu durchgeführten Aktionen zur späteren Weiterverarbeitung im Testkontext des jeweiligen Aktors hinterlegt werden. Somit beinhaltet der Kontext alle Informationen, die für die Durchführung eines Aktor-Dienstes notwendig sind, und dient als Parameter-Objekt. Auf der anderen Seite stellt der Kontext, als Modellelement, Testergebnisse bereit Aktoren können diese an den Kontext anhängen. Das Gesamtergebnis eines Testlaufs wird über eine Sitzung repräsentiert und beinhaltet alle erzeugten Testkontexte mit den angehängten Testergebnissen. Da der Anwendungskern keinerlei Kenntnis über den Inhalt der im Kontext verwalteten Informationen hat, wird ihm das Ergebnis der Verarbeitung über den Status des Testkontextes bereitgestellt. Dabei setzt sich der Status eines Kontextes aus den einzelnen Testergebnissen zusammen. Aus der Summe aller Status wird der Status eines Testlaufs bestimmt. Da aus Sicht des Controllers eine Gleichbehandlung von Aktoren, also Orakel und Testadapter, erfolgt, kann dieser die erforderlichen Testschritte nicht im Voraus berechnen. Weswegen der Anwendungskern es den Aktoren überlässt ihm mitzuteilen, wenn diese ihre Arbeiten abgeschlossen haben. Als Schnittstelle, zwischen Aktoren und Controller, dient hierzu wieder der Testkontext. Die Testabfolge gliedert sich in die Schritte, Überprüfung von Vorbedingungen, Anwendung eines Testadapters und abschlieÿende Überprüfung von Nachbedingungen. Die Einhaltung von Vor- und Nachbedingungen, für einen Test, werden durch die syntaktischen und semantischen Überprüfungen sichergestellt. Weist eine der Überprüfung auf Fehler hin, kann die Reaktion der Aktoren unterschiedlich sein. Während Orakel in der Regel die Ausführung nach dem ersten gefundenen Fehler abbrechen, werden Testadapter zum nächsten Testszenario wechseln. Zur syntaktischen Überprüfung eines Probanden wendet der Anwendungskern alle syntaktischen Orakel hintereinander an. Im Anschluss führt der Anwendungskern alle semantischen Überprüfung mit Hilfe der dafür vorgesehenen Orakel durch. Die resultierenden Testergebnisse (Modellelemente) werden dem Testkontext angehängt. Bei erfolgreichem Status des Testkontextes, d.h. in diesem Fall erfolgreicher syntaktischer und semantischer Überprüfung, wird ein Testadapter ausgewählt und so ein Refaktorisierungswerkzeug angewendet. Für den Fall, dass das Refaktorisierungswerkzeug angewendet werden konnte, werden im Anschluss wieder alle Probanden einer syntaktischen und semantischen 27

28 3 Lösungsansatz Analyse unterzogen und die Testergebnisse im Testkontext hinterlegt. Auch die Testadapter haben die Möglichkeit Informationen über das Refaktorisierungswerkzeug im Kontext zu hinterlegen, so z.b. die Beschreibung einer Refaktorisierung. Bevor zum nächsten Refaktorisierungswerkzeug gewechselt wird, werden alle Änderungen an den Probanden zurückgenommen, so dass für jede Refaktorisierung die gleichen Ausgangsbedingungen herrschen. 3.4 Steuerung und Überwachung von Aktoren Der beschriebene Testablauf, aus dem Unterkapitel 3.3, verdeutlicht, dass für die Steuerung und Überwachung von Aktoren, durch den Anwendungskern, unterschiedliche Kontrollüsse berücksichtigt werden müssen. Während alle Orakel hintereinander ausgeführt werden, wählt der Anwendungskern lediglich einen aktiven Testadapter zur Anwendung von Testszenarien aus. Damit der Anwendungskern den unterschiedlichen Anforderungen zur Steuerung und Überwachen von Aktoren gerecht wird, separiert er diese Aufgaben in eigene Komponenten Test-Runner. Der Anwendungskern, als Controller, delegiert seine Steuer- und Überwachungsaufgaben an diese Komponenten und erhält von ihnen die erforderlichen Statusmeldungen. Im Framework des Refactoring Tool Testers stellen Test-Runner lediglich weitere Aktoren dar, die aus den bereits eingeführten Aktoren (Orakel und Testadapter) zusammengefügt werden. Die Eigenschaft, das Aktoren hierarchisch aufgebaut sein können 3, liefert das Komponentenmodell. Das Testwerkzeug berücksichtigt diese Zusammenhänge in seinem Modell, in dem auch Testergebnisse (Modellelemente) hierarchisch aufgebaut werden. Die Abbildung 3.5 zeigt die beteiligten Komponenten zusammen mit ihren Kompositionen. Der Anwendungskern verwendet den Refaktorisierungs-Test-Runner zur Steuerung und Überwachung des Gesamtablaufs. Dieser setzt sich zusammen aus Testadaptern und Orakel-Runner. Der Refaktorisierungs-Test-Runner wendet einen Testadapter solange an, bis dieser ihm zurückmeldet, dass alle Refaktorisierungen für ein Werkzeug durchgeführt wurden. Danach wechselt er zum nächsten Testadapter. Vor und nach der Anwendung eines Testadapters weist der Refaktorisierungs-Test-Runner den Orakel-Runner an, die syntaktischen und semantischen Überprüfungen durchzuführen. Der Orakel-Runner setzt sich aus den kongurierten Orakeln zusammen. Da die Ausführbarkeit der Probanden vor der semantischen Überprüfungen gewährleistet sein muss, wendet der Orakel-Runner zuerst die syntaktischen und danach die semantischen Orakel an. 3 d.h. unter anderem können neue Aktoren durch (rekursive) Komposition von bereits vorhandenen realisiert werden 28

29 3 Lösungsansatz Abbildung 3.5: Koordinations-Komponenten des RTT 3.5 Testfälle für Refaktorisierungswerkzeuge Wie bereits im Unterkapitel 3.2 angedeutet, stellt das Testwerkzeug deklarative Testadapter bereit, die mittels Introspektion Testfälle für Refaktorisierungswerkzeuge anwenden. Einer dieser Testadapter ist der Abfragewerkzeug-Testadapter, der es Testern ermöglicht, durch Abfragen an Probanden zu refaktorisierende Programmstellen auszuwählen. Damit deklarative Testadapter anzuwendende Testfälle für Refaktorisierungswerkzeuge identizieren können, sind diese zu markieren bzw. annotieren. Für deklarative Testadapter sind im Framework des Testwerkzeug nachfolgende Annotationen festgelegt: Annotation Programmelement Öentliche Methode Markiert einen Testfall und speziziert ggf. die Abfrage zur Selektion der Methoden-Parameter Markiert einen Platzhalter für eine Variable aus der spezizierten Feld Markiert einen Platzhalter zur Anforderung von Sitzungsinformationen Tabelle 3.2: Annotationen für deklarative Testadapter Die Tabelle 3.2 zeigt die vorgesehenen Annotationen mit den für diese anwendbaren Programmelemente. So kennzeichnet beispielsweise die est einen Testfall für ein Refaktorisierungswerkzeug an einer öentlichen Methode. Ob die annotierte Methode dem Besitzerbereich (engl. scope) der Klasse oder der Instanz zugeordnet wird, ist dem Tester bei der Spezikation seines Testfalls überlassen. Ist ein Testfall im Besitzerbereich der Instanz deniert, wird vor Anwendung dieses Testfalls eine neue Instanz der zugehörigen Testklasse erzeugt. Somit wird jedem Testfall eine eigene Instanz zugeordnet, in 29

30 3 Lösungsansatz der dieser, isoliert von den anderen Testfällen, Zustandsinformationen ablegen kann. Des Weiteren beinhaltet die est die Möglichkeit zur Deklaration einer Abfrage in textueller Form. Die Syntax ist durch den ausführenden Abfragewerkzeug-Testadapter vorgegeben. Analog zur est markiert die estsession ein Feld innerhalb einer Klasse. Diese beinhaltet zur Laufzeit Sitzungsinformationen zum Testlauf, so z.b. die Probanden-Projekte oder Testkonguration. Die Belegung der Instanz des Feldes wird durch das Framework, vor der Anwendung eines Testfalls, übernommen, so dass durch den Tester keinerlei Initialisierung vorgenommen werden muss. Insbesondere besitzt die Testklasse keine direkt Abhängigkeit auf die zu instantiierende Testsitzung bzw. deren Implementierung, da diese Abhängigkeit durch das Framework injiziert (engl. dependency injection) wird. Dennoch wird der Datentyp des Feldes durch das Framework bzw. dem ausführenden Testadapter implizit vorgegeben und ist bei der Deklaration zu beachten. Auch bei annotierten Feldern ist der Besitzerbereich, Instanz oder Klasse, durch den Tester frei wählbar. Während die est estsession auch für andere deklarative Testadapter, als den Abfragewerkzeug-Testadapter, Verwendung nden, ist die estp aram speziell für diesen ausgelegt. Die estp aram bindet Variablen einer Abfrage, in einer vorgegebenen Abfragesprache, an ein Methoden-Argument. Dazu deniert der Tester in der Annotation den Namen der zu bindenden Variable, die durch die Abfrage deniert ist. Der Datentyp der Variable ist durch den ausführenden Testadapter, mit dem verwendeten Modell zur Repräsentation von Programmstellen, vorgegeben. Die Tupel, der aus der Abfrage resultierenden Ergebnismenge, werden über die deklarierten Methoden-Argumente bereitgestellt. Allein das Annotieren eines Testfalls reicht jedoch noch nicht aus, um ein Refaktorisierungswerkzeug automatisiert anzuwenden. Damit das Framework, des Testwerkzeugs, ein Refaktorisierungswerkzeug anwenden kann, muss der Testfall eine Refaktorisierungsbeschreibung zurückliefern. Diese beinhaltet neben dem Refaktorisierungswerkzeug, die zu refaktorisierenden Programmelemente und die gewählten Parameterwerte. Auch ist es notwendig, dass ein Tester die Möglichkeit hat in der Ergebnismenge seiner Abfrage zu navigieren, um beispielsweise festzulegen wann zum nächsten Tupel gewechselt wird. Womit ein Tester eine zu refaktorisierende Programmstelle für unterschiedliche Refaktorisierungs- Szenarien nutzen kann. Aus der Sicht des Testwerkzeugs zerfallen Testfällen in eine Menge von Testschritten. Jeder Testschritt umfasst dann eine Refaktorisierungsbeschreibung und die dazugehörige Kontrollussanweisung. In der Umsetzung des Refactoring Tool Tester ist der Rückgabewert eines Testfalls als T estp rocedurestep deniert. Die Abbildung 3.6 zeigt das Schema einer Testklasse zur Denition von Testfällen für Refaktorisierungswerkzeuge. Durch die hier vorgestellten Annotationen können Testfälle für Refaktorisierungswerkzeuge markiert und somit durch einen deklarativen Testadapter identiziert werden. Das Framework macht dabei keinerlei Vorgaben bezüglich des Aufbaus bzw. der Struktur von Testfällen. Sowohl die Namensgebung, Vererbungshierarchie als auch die Beziehungen zwischen Testklassen sind frei wählbar. Bei der Suche von Testfällen muss das Testwerkzeug die nachfolgenden Aspekte berücksichtigen: 30

31 3 Lösungsansatz 1 c l a s s MyTestclass 2 { TestSession 4 p r i v a t e T e s t C l i e n t S e s s i o n s e s s i o n ; 5 ( ) 7 TestProcedureStep mytestcase ( ) 8 { 9 R e f a c t o r i n g r e f a c t o r i n g = r e t u r n TestProcedureStep. c r e a t e ( r e f a c t o r i n g, FlowDecision.NEXT) ; 12 } } Abbildung 3.6: Schema einer Testklasse mit Testfällen für Refaktorisierungswerkzeuge Testfälle müssen für das Framework des Refactoring Tool Testers zugreifbar sein, d.h. sowohl die Testklasse als auch die annotierten Methoden. Die Testklasse, die zur Ausführung von Testfällen instantiiert wird, muss über den Standard-Konstruktor instantiierbar sein. Testfälle können abstrakt bzw. in abstrakten Testklassen oder Schnittstellen deklariert sein zur Ausführung werden dann die konkreten Subklassen herangezogen. 3.6 Grundlagen und Hilfsmittel Eclipse Eclipse, als integrierte Entwicklungsumgebung (IDE), ist eine Plattform, in der verschiedene Programmierwerkzeuge, z.b. die Java-Entwicklungswerkzeuge (JDT), transparent vereint werden. Die Eclipse-Plattform setzt sich dabei aus modularen Softwarebausteinen zusammen. Jeder Softwarebaustein stellt dafür eine Sammlung von Bibliotheken bereit, durch die die Funktionen und Fähigkeiten der IDE erweitert werden. Die Erweiterbarkeit der Plattform ist zentrales Architekturmerkmal für Eclipse und wurde von Beginn an durch ein Plugin-Konzept umgesetzt. Seit Version 3 stellt das OSGi-Framework, Equinox, die Basis für die Umsetzung von Plugins für Eclipse, womit diese dem OSGi- Komponentenmodell unterliegen. Seit dem entwickelt sich Eclipse zu einer Rich-Client- Plattform (RCP), die nicht nur Programmierwerkzeuge integriert, sondern aus deren Bestandteile beliebige Client-Anwendungen realisiert werden können. [8] Plugins Wie bereits angedeutet sind Plugins Softwarebausteine, die die Eclipse-Plattform um bestimmte Funktionen und Fähigkeiten erweitern. In Plugins können Pakete (und damit Klassen und Schnittstellen) und Ressourcen exportiert, Komponenten bereitgestellt oder auch ganze Anwendungen realisiert werden. Eclipse ist selber aus einer Ansammlung von Plugins realisiert. Beim Start der Plattform wird lediglich der Anwendungskern zur Bereitstellung der Plugin-Mechanismen gestartet. Erst durch die erste Anforderung eines 31

32 3 Lösungsansatz Abbildung 3.7: Erweiterungsbeziehungen zwischen Plugins [34] Plugins wird dieses, zusammen mit den zur Ausführung benötigten Plugins, gestartet. Ein Plugin enthält in der Regel, neben seinem Programmcode, alle benötigten Ressourcen sowie Metadateien, die das Plugin gegenüber dem System beschreiben. Wird ein neues Plugin installiert, sind keine weiteren Angaben zur Ausführung dieses Plugins notwendig. Die Metadatei enthält die notwendigen Informationen, so z.b. den Namen des Plugins, deren Version und die Namen der Plugins, vom denen dieses abhängig ist. Durch die explizite Bekanntgabe von Abhängigkeiten kann das System einen Abhängigkeitsgraphen erzeugen und so alle notwendigen Plugins, in der vorbestimmten Reihenfolge, bereitstellen. [15] Abhängigkeiten Es können zwei Formen von Abhängigkeiten zwischen Plugins unterscheiden werden, zum einen die einfache Abhängigkeitsbeziehung und zum anderen die Erweiterungsbeziehung. Ein Plugin geht eine einfache Abhängigkeitsbeziehung ein, wenn dieses Pakete oder Ressourcen aus einem anderen Plugin importiert (vorausgesetzt diese wurden durch das andere Plugin exportiert). Das importierende Plugin nimmt dabei die Rolle des abhängigen (engl. dependent), das exportierende die des vorausgesetzten (engl. prerequisite), Plugins ein. [15] Die Kennzeichnung der Rollen bzw. der Abhängigkeiten wird innerhalb der Metadateien explizit ausgewiesen. Hierfür gibt das vorausgesetzte Plugin, seine zu exportierenden Pakete bekannt. Das abhängige Plugin referenziert das vorausgesetzte Plugin entweder direkt über seinen Namen oder indirekt über die zu importierenden Pakete. Die zweite Form der Abhängigkeit, Erweiterungsbeziehung, wird zwischen Plugins über Erweiterungspunkte (engl. Extension-Point) und Erweiterungen (engl. Extension) eingegangen. Die Abbildung 3.7 zeigt die Struktur von Erweiterungsbe- 32

33 3 Lösungsansatz ziehungen zwischen Plugins mit Erweiterungspunkten und Erweiterungen. Dazu deniert ein Plugin einen Erweiterungspunkt über eine benötigte Schnittstelle (oder abstrakten Klasse) und veröentlicht diese in seiner plugin.xml zusammen mit einem Schema zur Beschreibung der Struktur des Erweiterungspunktes. Im Schema wird der Aufbau einer Erweiterung beschrieben und damit die bereitzustellenden Informationen bzw. Parameter festgelegt. Das Plugin, das eine Erweiterung für einen Erweiterungspunkt zur Verfügung stellt, deniert die geforderte Struktur des Schemas in seiner plugin.xml und macht damit die angebotene Realisierung bekannt. Die Auswertung der plugin.xml Datei erfolgt durch das System zur Übersetzungszeit, da sich diese zur Laufzeit nicht verändert. Bei der Verwendung von Erweiterungspunkten ist hingegen zu beachten, dass das System zur Laufzeit verändert werden kann zu jedem Zeitpunkt können Plugins hinzugefügt bzw. entfernt werden womit auch Erweiterungen hinzugefügt bzw. entfernt werden. Die Eclipse-Laufzeitumgebung benachrichtigt registrierte Beobachter über Veränderungen der Plugin-Registrierungen. Zur Behandlung der Dynamik stellt die Laufzeitumgebung Schnittstellen und Hilfsklassen über das Paket org.eclipse.core.runtime.dynamichelpers zur Verfügung, so z.b. IExtensionChangeHandler und ExtensionT racker. Oftmals wird dieser Sachverhalt bei der Behandlung von Erweiterungspunkten auÿer Acht gelassen, was einen Neustart der IDE nach Installation bzw. Deinstallation von Plugins erforderlich macht. Bündel Mit Einführung des OSGi-Komponentenmodells [18], in Eclipse, werden Plugins durch OSGi-Bündel (engl. bundle) repräsentiert. Es besteht dennoch ein Unterschied, denn Plugins erweitern OSGi-Bündel, um die Möglichkeit der Denition von Erweiterungsbeziehung (durch Erweiterungspunkte und Erweiterungen). Weswegen OSGi-Bündel das OSGi-Framework voraussetzten und Eclipse-Plugins die darauf aufsetzende Eclipse- Laufzeitumgebung. Grundsätzlich ist die Aufgaben eines OSGi-Bündels die Modularisierung einer Java-Anwendung. Hierzu zählen die Paketierung, die Verteilung sowie die Validierung von Anwendungen und Komponenten. [13] Zur Realisierung der Modularisierung und damit der Trennung verschiedener Programmaspekte liefert das OSGi-Framework zu jedem Bündel eine eigene Classloader-Instanz [15]. Classloader Der Classloader ist Bestandteil der virtuellen Java-Maschine (JVM) und dafür verantwortlich, dass Klassen in die virtuelle Maschine geladen werden. Beim Start der JVM, besitzt diese bereits einen System- bzw. Boot-Classloader, der dazu genutzt wird Klassen aus dem Classpath in die virtuelle Maschine zu laden. Durch Ableitung von der abstrakten Klasse java.lang.classloader kann die virtuelle Java-Maschine, um einen eigenen ClassLoader, erweitert werden. Der Classloader-Mechanismus des OSGi- Frameworks erweitert die virtuelle Java-Maschine um einen Bündel-Classloader. Die vorhandenen Classloader-Instanzen, des Boot-Classloader und der Bündel-Classloader, stehen über ein Delegationsnetzwerk miteinander in Verbindung. Kann ein Classloader eine Anforderung zum laden einer Klasse nicht erfüllen, leitet er diese an seinen benachbarten 33

34 3 Lösungsansatz Classloader weiter. Die Struktur des Delegationsnetzwerks hängt direkt von den deklarierten Bündel-Abhängigkeiten ab. Alle Anfragen die nicht durch einen Bündel-Classloader erfüllt werden können, werden abschlieÿend an den Boot-Classloader delegiert. Die Menge aller Klassen die über den Classloader eines Bündels bereitgestellt werden können, gehören zu seinem Class-Space. Der Class-Space eines Bündels beinhaltet demnach die Klassen: aus dem System-Classpath (Boot-Classloader), aus den importierten Paketen (indirekte Abhängigkeiten), aus den exportierten Paketen vorausgesetzter Bündel (direkte Abhängigkeiten) [15]. Durch den vorgestellten Classloader-Mechanismus ermöglicht das OSGi-Framework, dass verschiedene Bündel in derselben JVM laufen und trotzdem das Prinzip der Kapselung zwischen Bündeln nicht verletzt wird. Dies bedeutet, dass in derselben JVM ausgeführte Bündel alle Klassen bzw. Pakete vor anderen Bündeln verstecken, auÿer jene, die explizit exportiert werden. Sämtliche Klassen eines Class-Space müssen einen eindeutigen Namen haben. Namen von Klassen in verschiedenen Bündeln dürfen jedoch identisch sein, da diese nicht vom selben Classloader geladen werden. Durch diese Architektur unterstützt OSGi ein Modell, in dem mehrere Versionen der gleichen Klasse in eine JVM-Instanz geladen werden können. Dadurch können die Abhängigkeiten verschiedener Bündel optimal erfüllt werden, denn unterschiedliche Bündel können verschiedene Versionen der gleichen Klasse benötigen [13]. Dienste Im OSGi-Modell können Bündel Dienste deklarieren. Ein Dienst, im Sinne dieses Modells, wird semantisch durch seine Schnittstelle (engl. service interface) deklariert und durch ein Dienstobjekt (engl. service object) implementiert. Die Schnittstelle des Dienstes stellt die Spezikation seiner Methoden dar. Ein Dienstobjekt gehört zu einem Bündel und wird in dessen Kontext verwaltet. Dienste ermöglichen eine lose Koppelung der einzelnen Anwendungsbestandteile und erlauben dadurch die exible Wiederverwendung dieser, repräsentiert durch Bündel. Durch diese Architektur erlaubt das Modell die Trennung von Spezikation und Implementierung. Dazu exportiert ein Bündel eine Dienstschnittstelle während ein anderes die Implementierung dazu liefert. Insbesondere können auch mehrere Implementierungen des gleichen Dienstes verfügbar sein, d.h. mehrere Bündel stellen eine Implementierung einer Dienstschnittstelle bereit. Ebenso kann ein Dienstobjekt mehrere Dienstschnittstellen bedienen. Damit Dienste lokalisiert werden können, stellt das OSGi-Framework ein zentrales Dienstverzeichnis (engl. service registry) zur Verfügung, über das Dienste nachgeschlagen bzw. angefordert werden können. Die Abbildung 3.8 zeigt das Dienstverzeichnis des OSGi-Frameworks zur Darstellung der beschriebenen Zusammenhänge. Das Dienstverzeichnis steht somit als Vermittler von Diensten zwischen Bündel. Die Ausführung eines lokalisierten Dienstes erfolgt hingegen ohne Vermittlung, d.h. als direkter Funktionsaufruf da sich Klassen von Bündel in der gleichen JVM benden. Existieren mehrere Implementierungen eines Dienstes müssen sich diese ggf. unterscheiden lassen, dazu kann ein Dienstanbieter bei der Registrierung neben der Dienstschnittstelle zusätzliche Eigenschaften zu seinem Dienst denieren, die vom 34

35 3 Lösungsansatz Abbildung 3.8: Dienstverzeichnis des OSGi-Framework [29] Dienstnutzer zum Nachschlagen verwendet werden können. Abhängigkeiten zwischen dem Bündel, zu dem ein Dienst gehört, und den Bündeln, die diesen Dienst nutzen, werden vom Framework verwaltet. So werden registrierte Dienstnutzer über die Deregistrierung eines Dienstes ggf. benachrichtigt. [13] Vergleicht man die Mechanismen zur Entkopplung für Bündel mit denen für Plugins (also Dienste und Erweiterungsbeziehungen) sind Analogien festzustellen. Beispielsweise entspricht die Plugin-Registrierung dem zentralen Dienstverzeichnis. Auch die Rollen Nutzer und Anbieter können auf Erweiterungspunkte und Erweiterungen übertragen werden so übernimmt ein Erweiterungspunkt die Rolle eines Nutzers und die Erweiterungen die der Anbieter. Die Ansätze unterscheiden sich hingegen in der Multiplizität der Beziehung zwischen Nutzer und Anbieter während 1 Erweiterungspunkt N Erweiterungen aufnimmt, ermöglicht das OSGi-Modell N Dienstnutzer mit M Dienstanbietern zu verknüpfen. Für Bündel in denen Dienste konsumiert werden, gilt es die Dynamik des Systems zu beachten. Wie bereits für Erweiterungspunkte in Plugins stehen für das Konsumieren von Diensten Schnittstellen und Hilfsklassen zur Behandlung der Dynamik bereit. Das OSGi-Framework stellt zu diesem Zweck beispielsweise, über das Paket org.osgi.util.tracker, einen ServiceT racker zur Verfügung. Komponenten Betrachtet man das OSGi-Modell nach den Kriterien Semantik, Syntax und Komposition, erfüllen Bündel alle Kriterien für Komponenten (und damit auch Eclipse-Plugins). Die bereitgestellten Mechanismen zur Kollaboration, durch Dienste bzw. Erweiterungsbeziehungen, lassen das Bild einer zusammengesetzten Komponente erahnen. Wobei die Struktur, Aufgrund der losen Kopplung, keine starre Zusammensetzung von Komponenten zu neuen Komponenten ermöglicht. Insbesondere werden Bündel nicht so zusammengesetzt, dass zwei oder mehr Bündel zu einem neuen Bündel verschmelzen. Die Denition von Diensten ermöglichen die Trennung von Spezikation und Implementierung. Bündel sind dadurch nur von den Spezikationen der Dienste abhängig, die Implementierungen können (auch im laufenden Betrieb) nach Bedarf ausgetauscht werden. [13] Die lose Kopplung hat aber nicht nur Vorteile, denn der vorgestellte im- 35

36 3 Lösungsansatz Abbildung 3.9: Dienstkomponenten-Laufzeitumgebung [17] perative Ansatz, erhöht die Komplexität bei der Umsetzung von Bündel bzw. Plugins und ggf. deren Startzeit bzw. Speicherverbrauch. Wenn beispielsweise ein Dienst zur Ausführung andere zwingend benötigt, dann müssen die erforderlichen Dienste beobachtet und der abhängige, je nach deren Verfügbarkeit, registriert bzw. deregistriert werden. Des Weiteren werden beim imperativen Ansatz alle Dienste gleich beim Starten eines Bündels erzeugt und registriert, ganz unabhängig davon ob diese überhaupt jemals benötigt werden. Gerade bei Systemen, die aus zahlreichen Bündeln bestehen, kann dies leicht zur Erhöhung von Startzeit und Speicherverbrauch führen. Diese Probleme werden im OSGI-Komponentenmodell durch Einsatz eines deklarativen Dienstansatzes adressiert. In diesem werden Dienste durch Dienstkomponenten bereitgestellt und referenziert. Dienstkomponenten (engl. service component) bestehen aus einer XML-Beschreibung, der Komponentenbeschreibung (engl. component description), und einer Komponenteninstanz (engl. component instance). Die Komponentenbeschreibung beinhaltet alle notwendigen Informationen über eine Dienstkomponente, wie beispielsweise den Klassennamen (zur Instantiierung der Komponente) oder die bereitgestellten bzw. benötigten Dienstschnittstellen. Zum Zweck der Bekanntgabe wird die Komponentenbeschreibung in der Metadatei des Bündels bzw. Plugins eingetragen. Mit diesen Informationen instantiiert die Dienstkomponenten-Laufzeitumgebung (engl. service component runtime) Komponenten, wenn diese das erstmal angefordert werden und alle zwingend benötigten Abhängigkeiten verfügbar sind. Die Abbildung zeigt die Struktur der Dienstkomponenten- Laufzeitumgebung zur Darstellung der beschriebenen Zusammenhänge. Insbesondere entfällt die Notwendigkeit der Registrierung von Komponenten (und damit ggf. der Bündel- Aktivator), da Bündel durch die Laufzeitumgebung überwacht und so gefundene Dienst- 36

37 3 Lösungsansatz komponenten automatisch verfügbar gemacht werden. Explizit deklarierte Abhängigkeiten, auf Dienstschnittstellen, werden durch die Laufzeitumgebung ausgelöst und den Komponenten bereitgestellt. Des Weiteren übernimmt die Laufzeitumgebung das Life- Cycle-Management der Komponenten und deaktivierte diese, wenn Abhängigkeiten nicht mehr erfüllt werden können, weil Bündel bzw. Komponenten aus dem System entfernt wurden. Im deklarativen Ansatz kommen Komponenten ohne Abhängigkeiten auf das OSGi-Framework aus und werden daher durch einfache Java-Objekte (POJO) repräsentiert. Ein weiterer Vorteil, der sich dadurch ergibt, ist, dass Dienstkomponenten ohne die Laufzeitumgebung auf einfache Weise getestet werden können. [17] Es existieren weitere Frameworks die einen ähnlichen Ansatz verfolgen und auf dem OSGi-Komponentenmodell aufsetzen, zu den Vertreter gehören beispielsweise Spring Dynamic Modules, Apache Flex ipojo oder Guice Peaberry. Launching-Framework Zum Starten und Debuggen von Anwendungen bietet Eclipse Launcher, die durch das Eclipse-Launching-Framework ausgeführt werden. Wie alles in Eclipse werden Launcher durch Plugins bereitgestellt und sind daher nicht fester Bestandteil des Eclipse-Frameworks. Für jeden Anwendungstyp (Launch-Conguration-Type) kann für Eclipse ein eigener Launcher bereitgestellt werden. Im Eclipse-Softwareentwicklungskit (SDK) sind bereits diverse Launcher verfügbar, die beispielsweise das Debuggen und Starten von Java-Anwendungen, -Applets, JUnit-Testfällen oder Eclipse-Anwendungen ermöglichen. Die echte Stärke des Launching-Framework liegt jedoch in seiner Erweiterbarkeit durch eigene Launcher. Hierfür sind neben dem Launcher (Launch-Delegate), die Launch-Konguration und entsprechende Oberächen (Launch-Conguration- Tabs) bereitzustellen. In den Launch-Kongurationen wird die Persistierung der Kongurationen vorgenommen. Der Launcher ist für alle vorbereitenden Maÿnahmen und dem anwendungsspezischen Start zuständig. [27] Builder Wie jede moderne IDE bietet auch Eclipse dem Anwender die Möglichkeit Quellcode in ausführbaren Code zu übersetzen. Analog zu den Launchern ist auch diese Funktionalität nicht fester Bestandteil des Eclipse-Frameworks, sondern wird über Plugins (der JDT) bereitgestellt. Das Eclipse-Framework steuert über ein abstraktes Modell die dem Build-System bereitgestellten Komponenten Builder. Der Prozess der Übersetzung wird als Build-Vorgang bezeichnet und ist nicht nur auf Quellcode beschränkt. Zu jegliche Quell-Ressourcen, wie z.b. Kongurationsdateien, lassen sich Builder bereitstellen, die zu diesen abgeleitete Ressourcen erzeugen. Damit repräsentieren abgeleitete Ressourcen Ausgabedateien, die sich erneut aus den Quellen reproduzieren (ableiten) lassen. [22] Java Development Tools (JDT) Die JDT stellen die Entwicklungsumgebung für Java- Anwendungen in Eclipse. Sie sind Kernbestandteil des Eclipse-Softwareentwicklungskits. Mit Editoren, Assistenten, Vorlagen, Buildern und Refaktorisierungswerkzeugen stellen die JDT Funktionen zur Verfügung, die Entwickler bei der Erstellung von Java-Anwendungen unterstützen. Auch Launcher zum Debuggen und Starten von Java-Anwendungen, 37

38 3 Lösungsansatz -Applets oder enthaltenen JUnit-Testfällen werden durch die JDT bereitgestellt. Kern der JDT sind die Bestandteile, des Java-Modells, des abstrakten Syntaxbaums (AST) und der Java-Suchmaschine (engl. search engine). Diese stehen allen Erweiterungen zur Verfügung und erlauben das Navigieren, die Analyse und das Modizieren von Java-Programmen. [22] Plugin Development Environment (PDE) Eclipse-PDE, als Teil des Eclipse-Softwareentwicklungskit, bietet Werkzeugunterstützung zum Schreiben, Testen und Debuggen von Eclipse-Plugins und erweitert damit die Fähigkeiten der JDT. Dafür stellt das PDE eine Reihe von Assistenten und Vorlagen zur Verfügung, die die Erstellung von Plugins vereinfachen. Es gibt sowohl spezielle Editoren für Plugin- und Metadaten. Auÿerdem bietet das PDE einen Browser für die Erweiterungsregistratur und zur Darstellung von Abhängigkeiten zwischen Plugins. Es gibt Spezialfunktionen, die Zyklen in Abhängigkeiten aunden oder nicht verwendete Abhängigkeiten aufspüren. Auch bei der Denition von deklarativen Dienstkomponenten unterstützt das PDE mit entsprechenden Assistenten und Editoren. Eclipse ist eine komplizierte Plattform. Mit dem PDE ist es allerdings gelungen die zum Teil schwierigen Kongurationsarbeiten hinter graschen Oberächen zu verbergen [15]. Die Stärken des PDE zeigen sich insbesondere beim Testen und Debuggen von Plugins. Dort übernimmt das PDE alle notwendigen Schritte, von der Konguration bis hin zur Bereitstellung einer autonomen Arbeitsumgebung (Testumgebung), für die zu testenden Plugins (und allen zur Ausführung notwendigen). Durch das PDE werden Launcher für das Starten und Debuggen von Eclipse-Anwendungen und den darin enthaltenen JUnit-Testfällen bereitgestellt. Zur Isolation von zu testenden Plugins wird durch das PDE eine Testumgebung, in einer neuen Eclipse-Instanz, gestartet. Womit gewährleistet ist, dass die produktive Umgebung, von Fehlern und Ausnahmen in zu testenden Plugins, unbeeinusst bleibt (da jede Instanz in einer separaten JVM läuft). Team Die Team-Komponente dient als Basis für die Entwicklung von Versions- und Kongurationsmanagement-Systemen (VCM) in Eclipse und erlaubt dadurch die gleichzeitige Nutzung von Ressourcen innerhalb einer Entwicklergruppe. Dazu wird ein Projekt mit einem Repository verknüpft, das die Verwaltung übernimmt. Über das Repository steht das Projekt, und Informationen (z.b. die Historie) über das Projekt, den Team- Mitgliedern zur Verfügung. Im Eclipse-SDK ist eine konkrete Implementierung für CVS enthalten. Für den Nachfolger, von CVS, SVN stehen die Plugins Subversive oder Subclipse bereit. Des Weiteren bieten verschiedene Hersteller, wie z.b. Rational, Serena, Starbase oder Merant, Integrationen (eigene Plugins) für ihre Produkte an [35]. JQuery JQuery ist ein Werkzeug zur abfragebasierten Suche im Quellcode ein abfragebasierter (engl. query-based) Java-Quellcode-Browser. Es ist als Eclipse-Plugin realisiert und arbeitet auf Basis der logischen Abfragesprache TyRuBa, die eine Prolog-ähnliche Syntax besitzt. Aus dem AST der ausgewählten Java-Projekte werden durch JQuery die notwendigen Fakten für die TyRuBa-Datenbank generiert. Im Anschluss kann der 38

39 3 Lösungsansatz Quellcode nach Kriterien einer Abfrage untersucht werden. Die Ergebnisse einer Abfrage werden automatisch an den Quellcode gebunden, der durch das Java-Modell der JDT repräsentiert wird. Dadurch ist eine Navigation zwischen Abfragen-Ergebnis und Quellcode möglich. Mit diesen Mitteln können Benutzer Ansichten denieren und die gewünschten Aspekt ihrer Programme visualisieren. [3] SWT und JFace Im Umfang der Standard Java-Bibliothek sind Klassen und Schnittstellen, auf Basis der Bibliotheken Swing und Abstract Window Toolkit (AWT), zur Realisierung von graschen Benutzeroberächen enthalten. Eclipse-Anwendungen nutzen jedoch die Bibliothek des Standard Widget Toolkits (SWT) zur Realisierung von Benutzeroberächen. Anders als die Bibliotheken, die im Standard-Umfang enthalten sind, implementiert SWT seinen Funktionen ausschlieÿlich auf Basis des Betriebssystems. Hierdurch betten sich SWT-Anwendungen vollständig in die zugrunde liegende Desktopumgebung ein und haben nicht das für Java-Programme typische Aussehen und zum Teil schwerfällige Fensterverhalten. Anderseits geht damit ein Teil der Flexibilität verloren, da das SWT abhängig von dem Umfang der unterstützen Funktionen des Betriebssystems ist. Zudem müssen Programmierer die Freigabe von System-Ressourcen (wie z.b. Farben oder Schriftarten) explizit anweisen, da diese Ressourcen von der automatischen Speicherbereinigung (GC) nicht freigegeben werden (insbesondere weil sie zwischen Steuerelementen wiederverwendet werden und der GC nicht über die notwendigen Informationen verfügt). Aufbauend auf dem SWT stellt JFace seine Steuerelemente (z.b. Bäume, Listen, Wizards oder Dialoge) bereit, die Entwickler bei der Umsetzung von graschen Oberächen unterstützen. Das Plugin der Eclipse Benutzerschnittstelle (UI) realisiert auf Basis dieser Bibliotheken bzw. Plugins, SWT und JFace, Benutzeroberächen und Standarddialoge, die zusammen die Workbench für eine Eclipse-Anwendung realisieren. [15] 39

40 4 Implementierung 4.1 Organisation Plugins Der Refactoring Tool Testers unterteilt seine Programmaspekte in verschiedene Plugins, die die notwendigen Komponenten bereitstellen. Zu diesen Komponenten (bzw. Plugins) gehören: de.fernunihagen.rtt ist das RTT-Core-Plugin und beinhaltet alle von der Benutzerschnittstelle unabhängigen Programmaspekte. Dazu gehören Annotationen für deklarative Testadapter, Schnittstellen zur Denition von Dienstkomponenten (wie z.b. Testadapter, Orakel, Repositories und Test-Runner), das Modell und der Anwendungskern, der die Koordinationslogik beinhaltet. Des Weiteren stellt das Core- Plugin konkrete Implementierungen für das syntaktische, semantische Java-Orakel und den dazugehörigen Test-Runnern zur Verfügung. de.fernunihagen.rtt.thirdparty kapselt eine Sammlung von Java-Bibliotheken (in Jar-- Archiven), auf die RTT-Plugins Abhängigkeiten haben, die aber nicht Teil der RTTeigenen Implementierung sind. Dazu gehören beispielsweise Contract4J oder Log4J. de.fernunihagen.rtt.framework.repository.team.svn stellt einen Konnektor zur Anbindung von SVN Repositories, durch Subversive, zur Verfügung. de.fernunihagen.rtt.ui ist das RTT-UI-Plugin und enthält alle Komponenten der Benutzerschnittstelle. Dazu gehören eine Ansicht zur Darstellung und Analyse von Testergebnissen und ein Kongurationsassistent. Des Weiteren stellt das Plugin Schnittstellen zur Denition von Dienstkomponenten zur Verfügung, die der Erweiterung der Ansicht bzw. Analyse-Fähigkeiten dienen. Zudem erweitert das Plugin das Launching-Framework um einen Launcher zum Start und Debuggen von Tests. Neben diesen Bestandteilen stellt das UI-Plugin konkrete Implementierungen für einen deklarativen Java-Testadapter (ohne Abfragewerkzeug) und verschiedene Analyse-Werkzeuge zur Verfügung. de.fernunihagen.rtt.ui.app beinhaltet den Prüfstand (engl. test bench), der vom Launcher verwendet wird, um Tests isoliert auszuführen. Die Mittel zur Darstellung und Analyse von Testergebnissen, die durch das RTT-UI-Plugin bereitgestellt werden, sind in der Testbench verfügbar. 40

41 4 Implementierung Abbildung 4.1: Schichten des Refactoring Tool Testers de.fernunihagen.rtt.ui.testadapter.jquery enthält einen deklarativen Abfragewerkzeug- Testadapter, der JQuery verwendet (JQuery-Testadapter) Abhängigkeiten Die Umsetzung des Testwerkzeugs ist in den, in Abbildung 4.1, gezeigten Schichten unterteilt. Die Plugins, aus dem Unterkapitel 4.1.1, sind diesen Schichten zugeordnet. Des Weiteren zeigt die Abbildung 4.1 die internen Abhängigkeiten, zwischen den Plugins, des Testwerkzeugs. Dabei ist die Richtung der Abhängigkeiten durch die dargestellten Pfeile ausgewiesen. Die Plugins der Benutzerschnittstelle, de.f ernunihagen.rtt.ui.testadapter.jquery, de.f ernunihagen.rtt.ui und de.f ernunihagen.rtt.ui.app, sind der Präsentationsschicht zugeordnet. Die RTT SVN-Anbindung, de.f ernunihagen.rtt.f ramework.repository. team.svn, stellt die Brücke zur Datenhaltung von Probanden in Repositories. Die Anwendungslogik wird durch das Plugin de.f ernunihagen.rtt bereitgestellt. Das de.f ernunihagen.rtt.thirdparty Plugin beinhaltet alle verwendeten, nicht in Eclipse enthaltenen, Drittanbieter-Bibliotheken. Die Zuordnung des deklarativen JQuery-Testadapters zur Präsentationsschicht ist Aufgrund der fehlenden Trennung, zwischen Benutzerschnittstelle und Anwendungslogik, vieler Refaktorisierungswerkzeuge erfolgt. Diese benötigen zur Ausführungen einen UI-Thread, um die Konsistenz ihrer Datenstrukturen zu gewährleisten. Für Testfälle auf Basis dieses Testadapters entfallen die Abhängigkeiten auf die Benutzerschnittstelle des RTT, da der Testfall durch das Framework ausgeführt wird, das diese verbirgt. Damit beschränken sich die Abhängigkeiten, die zur Deklaration von Testfällen für Refaktorisierungswerkzeuge notwendig sind, auf das RTT-Core Plugin. 41

42 4 Implementierung Pakete Die Organisation von Klassen, Schnittstellen und Annotationen, des Refactoring Tool Testers, unterteilt sich in Pakete. Diese werden durch die im Unterkapitel beschriebenen Plugins exportiert. Konkrete Implementierungen sind in internen (engl. internal) Paketen organisiert, die damit fragile Programmierschnittstellen kennzeichnen d.h. die dort enthaltenen Programmelemente können jeglicher Art von Änderung, zwischen zwei Plugin-Versionen, unterliegen. Im Gegensatz dazu enthalten die verbleibenden Pakete externe Programmierschnittstellen, die zur Sicherung der Kompatibilität, zwischen Nutzer und Anbieter einer Programmierschnittstelle, keinen Änderungen unterliegen. Verwendete Technologien bzw. Abhängigkeiten auf andere Werkzeuge sind in den Paketnamen implizit ausgewiesen, so z.b. JDT oder SVN Klassen auÿerhalb dieser Pakete haben keine Abhängigkeiten auf diese Werkzeuge. Damit gewährleistet das Testwerkzeug, dass Abhängigkeiten auf andere Werkzeuge in zentralen Paketen organisiert sind und erreicht damit seine Erweiterbarkeit, um beispielsweise Testadapter für Refaktorisierungswerkzeuge anderer Programmiersprachen. Eine tabellarische Übersicht über die realisierte Paketstruktur ist dem Anhang, in den Tabellen A.2, A.4 und A.6, beigefügt. 4.2 Framework Struktur Wie bereits angedeutet ist der Refactoring Tool Tester als Framework, für das automatisierte Testen von Refaktorisierungswerkzeugen, entworfen. Das Testwerkzeug ist damit um neue Testadapter, Orakel, Test-Runner, Repositories und Analyse-Werkzeuge erweiterbar. Die zentralen Konzepte zur Erweiterung des Testwerkzeuges stellt das OSGi- Komponentenmodell mit Bündeln und Dienstkomponenten. Auch wenn Eclipse seit Version 3 auf OSGi basiert, nutzen nur wenige Plugins die neuen Möglichkeiten des OSGi- Frameworks aus. Von daher sind Plugins, die Dienste bzw. Dienstkomponenten denieren, eher selten aufzunden. Erweiterungsbeziehungen zwischen Plugins sind immer noch der zentrale Mechanismus um Eclipse zu erweitern, so dass das Testwerkzeug auf Erweiterungen zurückgreifen muss, um an bestehende Funktionalitäten anzuknüpfen. Jedoch werden Erweiterungspunkte vom Testwerkzeug nicht bereitgestellt hier kommen Dienstkomponenten zum Einsatz. Die Probleme, die sich dadurch ergeben, dass man sich nicht nur in der Welt der Dienstkomponenten bewegt, sind, dass Dienste auÿerhalb der Dienstkomponenten-Deklarationen verfügbar gemacht werden müssen. Aus diesem Grund setzt das Framework, des Testwerkzeuges, neben dem deklarativen Dienstansatz, auch den imperativen ein. Hierzu stellt das Framework Fassaden (RT T Core und RT T CoreUI) zum Zugri auf Dienste auÿerhalb der Dienstkomponenten-Deklaration bereit. Die Abbildung 4.2 zeigt eine Übersicht über die interne Struktur des RTT-Core-Plugins und weist verwendete Schnittstellen und Komponenten aus. Zur Realisierung der Fassade RT T Core 42

43 4 Implementierung Abbildung 4.2: Übersicht der RTT-Core Komponentenstruktur kommen Anbieter als Dienstkomponenten zum Einsatz, die die Verwaltung und den Zugri auf die RTT Dienste von Orakeln, Testadaptern, Repositories und Beobachtern ermöglichen. Die gezeigten Anbieter und Test-Runner werden durch das RTT-Core-Plugin mit Hilfe von ServiceTrackern referenziert. Über die Schnittstelle der Fassade können diese konguriert werden. Vor dem Start eines Testlaufs bestimmt der Anwendungskern, über die Fassade, die aktiven Anbieter (engl. provider) und Test-Runner. Die enthaltenen Orakel, Java-Übersetzer und JUnit, sind als Dienstkomponenten über die gleichnamigen Schnittstellen realisiert. Die Registrierung wird vor dem Start des Plugins, wie für alle Dienstkomponenten, durch die OSGi-Laufzeitumgebung übernommen. Die Abbildung 4.3 vervollständigt das Bild der RTT-Komponentenstruktur, aus Abbildung 4.2, um die verbleibenden Plugins. Analog zur RTT-Core-Fassade stellt die RTT- Core-UI-Fassade die aktiven Dienstanbieter der Benutzerschnittstelle bereit. Zu diesen Dienstanbietern gehört der Anbieter für Aktionen der Benutzerschnittstelle, der die Verwaltung und Bereitstellung von Kontext-Menü-Einträgen für die Testergebnisansicht übernimmt. Weitere Dienstkomponenten des RTT-UI-Plugins sind der Inhaltsanbieter für Testergebnisse, der deklarative Java-Testadapter und konkrete Implementierungen für Aktionen 1 der Testergebnisansicht (z.b. Wiederholung einer Refaktorisierung). Die Testergebnisansicht ist als Erweiterung, des Erweiterungspunktes org.eclipse.ui.views, realisiert. Des Weiteren erweitert das RTT-UI-Plugin das Launching-Framework um einen 1 Diese sind aus Gründen der Übersichtlichkeit nicht im Komponentendiagramm aufgeführt. 43

44 4 Implementierung Abbildung 4.3: Übersicht der RTT Komponentenstruktur Launcher zum Starten und Debuggen von Tests. Zu den Bestandteilen der Erweiterungen gehören die Launch-Kongurations-Registergruppe (engl. launch conguration tab group) und der Launch-Delegate. Während die konkreten Implementierungen der Launch- Kongurations-Registergruppe und der dazugehörigen Registerkarten im RTT-UI-Plugin enthalten sind, ist die Implementierung des Launch-Delegates Teil des Testbench-Plugins (de.f ernunihagen.rtt.ui.app). Das Testbench-Plugin beinhaltet eine Erweiterung zum Erweiterungspunkt Applikation (org.eclipse.core.runtime.applications), der den Startpunkt einer Eclipse-Anwendung auszeichnet. Über diese Erweiterung startet der Launcher die Testbench in einer neuen Eclipse-Instanz. Im Anschluss bestimmt die Testbench über den gleichen Erweiterungspunkt die zu startende Workbench-Anwendung, um dem Tester eine grasche Oberäche bereitzustellen. Vor dem Start der Workbench-Anwendung registriert sich die Testbench als Test-Harnisch (engl. test harness) bei der Eclipse-Plattform, um mit dem Start der Workbench zurückgerufen zu werden. In der Rückruf-Funktion (engl. callback-function) erfolgt der Start des Anwendungskerns. Alle notwendigen Parameter sind in der Testkonguration enthalten, die vom Launcher als temporäre XML-Datei vor dem Start hinterlegt wird. Als Übergabeparameter wird durch die Ausführungskette Testbench-, Workbench- Anwendung und Anwendungskern die URI der Testkonguration delegiert. Die verbleibenden Plugins, JQuery-Testadapter und Team-SVN-Konnektor, beinhalten die Realisierungen der Schnittstellen Testadapter und Repository als Dienstkomponenten. 44

45 4 Implementierung Abbildung 4.4: Übersicht der RTT Modellelemente Modell Wie im Unterkapitel 3.2 beschrieben, ist der RTT nach dem MVC-Architekturmuster entworfen. Das Modell wird zur Entkopplung der Präsentationsschicht von der Anwendungslogik verwendet. Hierzu benachrichtigt der Anwendungskern Beobachter (z.b. Analysewerkzeuge) über Modelländerungen. Das Modell beinhaltet alle Kongurationsparameter und Testergebnisse, die zur Analyse notwendig sind. Da der Anwendungskern mit seinen Aktoren hierarchisch aufgebaut ist, spiegelt das Modell diese Struktur wieder und ist deswegen nach dem Composite-Entwurfsmuster realisiert. Damit stehen Modellelemente in einer Teil-Ganzes-Hierarchie in Beziehung, die das Modell als Baumstruktur präsentiert. Die Abbildung 4.4 gibt einen Überblick über die Klassen-Hierarchie der Modellelemente, als UML-Klassendiagramm. Die Klasse AbstractT estelement stellt die Basis-Klasse aller Modellelemente in der Klassen-Hierarchie dar. Kindelemente haben die abstrakte Klasse T estelement als Basis-Klasse und repräsentieren damit, in der Teil-Ganzes-Hierarchie, atomare Test- bzw. Teilergebnisse (z.b. Ausnahmen, Übersetzungsprobleme oder Informationen über eine Refaktorisierung). Zusammengesetzte Testergebnisse (z.b. Testkontext oder Testsitzung) werden durch Ableitung von der Basis-Klasse AbstractT estelementcontainer realisiert. Die gezeigte Struktur erlaubt, dass Kompositionen von Testergebnissen rekursiv aufgebaut werden. Klassiziert man die Klassen AbstractT estelementcontainer und T estelement nach ihren Rollen, übernehmen die 45

46 4 Implementierung Behälter (AbstractT estelementcontainer) die Vater-Rollen und die enthaltenen Teilbzw. Testergebnisse (T estelement) die der Kinder. Die Navigation zwischen diesen Modellelementen ist sowohl in Richtung der Väter als auch der Kinder möglich, so dass von jedem Punkt aus alle Modellelemente zugreifbar sind. Die Beziehungen zwischen den zusammengesetzten und atomaren Testergebnissen werden im Modell über Schnittstellen, IT estelement und IT estelementcontainer, abgebildet und ermöglichen damit den Austausch der Implementierung. Des Weiteren führt das Modell die im Unterkapitel 3.3 beschriebenen Modellelemente und die dazugehörigen Schnittstellen, Testkontext (T estcontext) und Testsitzung (T estrunsession), ein. Die Sitzung fasst das gesamte Modell, über die einzelnen Testkontexte, zusammen und wird im Diagramm durch den Einstiegspunkt des Anwendungskerns, die T oolt estapplication, repräsentiert. Da Testsitzungen, in diesem Modell, zusammengesetzt sein können, ist eine Unterscheidung zwischen T estrunsession und T estrootrunsession notwendig. Die T estrootrunsession repräsentiert im Modell den dedizierten Einstiegspunkt, der alle Sitzungen zusammenfasst und für sich selber die Vater-Rolle übernimmt (rekursive Struktur). Neben dem Zugri auf Testergebnisse ermöglicht die Testsitzung den Zugri auf die Testkonguration und die zu verwendenden Probanden-Projekte, die alle Kontexte einer Sitzung gemeinsam haben. Eine ähnliche Struktur weisen die enthaltenen Testkontexte, T estcontext und T estrootcontext, auf. Wobei der T estrootcontext sich nicht selber referenziert, sondern lediglich einen Startpunkt innerhalb einer Sitzung qualiziert d.h. die Vater-Rolle für einen T estrootcontext wird immer durch eine Testsitzung übernommen. Jeder Testkontext ermöglicht, indirekt über die Sitzung, den Zugri auf Probanden und die Testkonguration. Des Weiteren stellt ein Kontext den Bezug zu seinem Aktor her, so dass die enthaltenen Testergebnisse diesem zugeordnet werden können. Über die Schnittstelle IObservable, der T estrootrunsession, können Beobachter für Änderungen des gesamten Modells registriert werden. Die Registrierung von Dienstkomponenten als Modell-Beobachter wird durch die T oolt estapplication vor dem Start eines Testlaufs übernommen. Die Abbildung 4.5 zeigt die Denition der, in Abbildung 4.4 gezeigten, Schnittstellen und deren Beziehungen. Die Basisschnittstelle IT estelement deniert den Zugri auf den Vater-Behälter und die Testsitzung. Neben diesen Bestandteilen stehen Dienste zur Abfrage von Status- (z.b. Verarbeitungsergebnis, Verarbeitungszustand oder Durchlaufzeit) und Anzeige-Informationen (z.b. Anzeigename) zur Verfügung. Das Verarbeitungsergebnis (Result) ermöglicht es einem übergeordneten Controller (z.b. Test-Runner), ohne die Struktur der Modellelemente zu kennen, den Kontrolluss zu steuern. Diese werden durch eine Aufzählung (engl. enumeration) repräsentiert und können miteinander verknüpft werden. Es werden die Verarbeitungsergebnisse aus Tabelle 4.1 unterschieden. In dieser De- nition besitzt jede Konstante eine Kardinalität, die die Wertigkeit des Ergebnisses im Zweierkomplement kennzeichnet. Durch Akkumulation werden zwei oder mehr Ergebnisse verknüpft, die resultierende Zahl kennzeichnet mit dem höchstwertigen Bit die Kardinalität des zusammengesetzten Ergebnisses. Wird beispielsweise das Verarbeitungsergebnis OK mit einem ERROR verknüpft, ist das resultierende Verarbeitungsergebnis ERROR. 46

47 4 Implementierung Abbildung 4.5: Schnittstellen des RTT Modells Name Kardinalität Bedeutung NONE 1 Besitzt kein Verarbeitungsergebnis IGNORED 2 Element wurde von der Verarbeitung ausgeschlossen OK 4 Erfolgreiche Verarbeitung FAILURE 8 Aufgedeckter Fehler ERROR 16 Ausnahmefehler in der Verarbeitung UNDEFINED 32 Verarbeitungsergebnis ist nicht verfügbar Tabelle 4.1: Verarbeitungsergebnisse im RTT Modell Übertragen auf zusammengesetzte Testergebnisse führt der Fehlschlag eines Teilergebnisses zum Fehlschlag des Ganzen. Die Tabelle 4.1 gibt einen Überblick über die verfügbaren Verarbeitungsergebnisse zusammen mit ihren Kardinalitäten und den zugeordneten Bedeutungen. Modellelemente ohne Verarbeitungsergebnis kennzeichnen dies über den Status N ON E. Modellelemente, denen ein Verarbeitungsergebnis zugeordnet werden kann, werden mit dem Status U N DEF IN ED initialisiert, um die ausstehende Bearbeitung zu kennzeichnen. Nach Abschluss erfolgt der Wechsel in einen Erfolgs- (OK) oder Fehlerstatus (F AILU RE oder ERROR). Das Verarbeitungsergebnis F AILU RE weist auf einen syntaktischen oder semantischen Fehler hin, ohne dass in der Verarbeitung Ausnahmen (engl. exceptions) aufgetreten sind. Im Vergleich dazu kennzeichnet der Status ERROR einen Fehler, der durch das Auftreten einer Ausnahme ausgelöst wurde. Dabei können Ausnahmen durch Aktoren 47

48 4 Implementierung Abbildung 4.6: Verarbeitungszustände eines Modellelements oder von diesen ausgeführten Testfällen ausgelöst werden - d.h. auch in JUnit-Testfällen. Für den Fall das eine Ausnahme nach Refaktorisierung in einem JUnit-Testfall ausgelöst wird, deutet dies auf einen semantischen Fehler hin. Von der Verarbeitung ausgeschlossene Elemente werden durch IGN ORED gekennzeichnet. Neben den Verarbeitungsergebnissen unterscheiden die Aktoren Ausführungsstadien (engl. run stages), die Kennzeichnen in welchem Stadium sich die Verarbeitung bendet. Zu den Ausführungsstadien gehören die Initialisierung (INIT), Ausführung (RUN) und Bereinigung (DISP OSE). Mit diesen Informationen kann ein Modellelement der Verarbeitungsphase eines Aktors zugeordnet werden. Zusammengesetzte Testergebnisse werden durch die Schnittstelle IT estelementcontainer repräsentiert, die dafür die Schnittstelle IT estelement erweitert. Analog dazu erweitern die Schnittstellen Testkontext und Testsitzung die Behälter-Schnittstelle (IT estelementcontainer), z.b. um den Zugri auf Probanden-Projekte. Des Weiteren können im Testkontext Zwischenergebnisse für einen Aktor hinterlegt werden, diese werden durch einen Aktor-Zustand (IT estactorstate) repräsentiert. Kenntnis über den Aufbau des Aktor-Zustands hat nur der jeweilige Aktor. Aus diesem Zusammenhang geht hervor, dass ein Kontext nur in Verbindung mit seinem Erzeuger verwendet werden kann. Wird ein Kontext einem anderen Aktor, als dem Erzeuger, zugewiesen, führt dies in der Regel zu Ausnahmefehlern. Die Testsitzung deniert Dienste zum Zugri auf die Testkon- guration, dabei kann die gesamte oder nur die Aktor-eigene Konguration erfragt werden. Benachrichtigungen über Änderungen werden durch die Modellelemente, über den Dienst notif ychange, generiert in Regel getrieben durch einen Wechsel der Verarbeitungszustände (P rogressstate). Die Abbildung 4.6 zeigt die Verarbeitungszustände eines Modellelements in Verbindung mit den erlaubten Transitionen. Nach Initialisierung eines Modellelements ist dieses im Zustand N OT_ST ART ED. Durch Start eines Testlaufs erfolgt, über einen Controller (z.b. einen Aktor), der Zustandswechsel eines Modellelements in den Zustand RU N N IN G. Für Modellelemente mit Anzeigeinformationen (z.b. Refaktorisierungsparameter) kann der Zustandswechsel auch direkt in den Zustand COM P LET ED erfolgen. Durch Anhalten der Verarbeitung wird ein beteiligtes Modellelement in den Zustand ST OP P ED überführt, aus dem es wieder in den Zustand RUNNING zurückgeführt werden kann. Vor dem Neustart (Reset) einer Verarbeitung werden Modellelemente, 48

49 4 Implementierung Name Kardinalität Bedeutung NOT_STARTED 1 Verarbeitung noch nicht begonnen COMPLETED 2 Verarbeitung abgeschlossen RUNNING 4 in Verarbeitung STOPPED 8 Verarbeitung angehalten Tabelle 4.2: Verarbeitungszuständen im RTT Modell vom Zustand COMP LET ED, in den Zustand NOT_ST ART ED zurückversetzt. Noch laufende Verarbeitung im Zustand RUNNING werden angehalten und vom Zustand ST OP P ED in den Zustand N OT_ST ART ED überführt. Genau wie die Verarbeitungsergebnisse werden Verarbeitungszustände durch eine Aufzählung repräsentiert und können Analog dazu kombiniert werden. Die Tabelle 4.2 zeigt eine Übersicht über die verfügbaren Verarbeitungszustände zusammen mit ihren Kardinalitäten und den zugeordneten Bedeutungen. Die Durchlaufzeiten der Verarbeitung werden vom Start bis zum Anhalten bzw. dem Verarbeitungsende gemessen. Die Wartezeiten bei Unterbrechung durch höher-priore Tasks gehen in die Messungen ein. Weiterhin stellt die Testsitzung Filter für direkte bzw. indirekte Testziele zur Verfügung. Die indirekten Testziele sind beispielsweise anzuwendende JUnit-Testfälle die nur beiläuge durch eine Refaktorisierung geändert, aber nicht als direkte Eingaben für ein Refaktorisierungswerkzeug verwendet, werden sollten. Durch die Anwendung der Filter können Testadapter (und Testfälle für Refaktorisierungswerkzeuge) diese Programmelemente identizieren und ausschlieÿen. Bereitgestellt werden diese Filter durch Orakel, wie z.b. das semantische JUnit-Orakel. Durch Verknüpfung der bereitgestellten Filter entsteht der resultierende Filter für die direkten Testziele Konguration Wie bereits angemerkt, wird die Testkonguration durch den Launcher, als temporäre XML-Datei, erzeugt. Da der Launcher eine eigene Konguration besitzt, die Launch- Konguration, ist die Testkonguration in diese eingebettet. Das Format der Testkonguration, als XML-Datei, erlaubt die Abbildung des im Unterkapitel 3.2 beschriebenen Schemas. Insbesondere ist das Format, Aufgrund der Möglichkeiten zur Strukturierung von Daten, geeignet, um hierarchische Strukturen zu beschreiben. Die Abbildung 4.7 zeigt die Schnittstelle der Testkonguration zusammen mit der bereitgestellt Implementierung als XML-Testkonguration. Die Schnittstelle IT estconf iguration ermöglicht es, dass die Instanz einer Testkonguration sowohl die gesamte Konguration als auch nur einen Teilausschnitt repräsentiert. Die gesamte Konguration setzt sich aus den zugrunde liegenden Teilkongurationen (Probanden, Orakel und Testadapter) zusammen. Die Dienste der Konguration erlauben die Analyse und Manipulation enthaltener Daten. Um die Testkonguration variable zu gestalten, sind die festgelegten Tags und Attribute nicht Bestandteil der Konguration, sondern der Testbeschreibung und als Konstanten in 49

50 4 Implementierung Abbildung 4.7: Schnittstellen und Klassen der Testkonguration der Schnittstelle IT estdescription deniert. Die Implementierung der Testbeschreibung kapselt den Zugri auf die Datenstrukturen der Testkonguration durch Bereitstellung geeigneter Dienste. Beispielsweise ermöglicht die Implementierung der Refaktorisierungs- Testbeschreibung (Ref actoringt estdescription) Testklassen aus den, in der Beschreibung denierten, Testbündeln zu laden und die enthaltenen Testfälle aufzunden. Hierzu verwendet die Implementierung, neben der Testkonguration, die Java-Introspektion und die Bündel-Classloader des OSGi-Frameworks. Die Auistung in Abbildung 4.8 zeigt die schematische Struktur der umgesetzten XML- Testkonguration. Dabei beinhaltet die Sektion projects die Proband-Konguration. Die Aufschlüsselung von Probanden-Projekten (project) erfolgt, mittels eindeutiger Schlüssel (ID), Anbieter (provider) spezisch. Teil der Probanden-ID (projectid) ist implizit die Repository-ID. Die Aktor-Konguration ist Teil der Sektion actor. In dieser Sektion sind Aktoren, Orakel und Testadapter, explizit ausgewiesen. Die Steuerung des Ausnahmeverhaltens kann über den Status des Attributes continueonerror beeinusst werden. Von der Aktor-Konguration ausgeschlossene Programmelemente (z.b. Ressourcen) werden über die Tags exclude gekennzeichnet, wobei die IDs Aktor-spezisch interpretiert werden. Die Testbündel-Konguration eines deklarativen Testadapters ist in der gleichnamigen Sektion (testbundle) aufgeführt. Die Auswahl von Testfällen erfolgt indirekt über die Auswahl von Testklassen, so dass einzelne Testfälle nicht ausgewählt bzw. ausgeschlossen 2 werden können. 2 Auÿer durch auskommentieren der Annotationen eines Testfalls im Programm 50

51 4 Implementierung 1 <c o n f i g u r a t i o n > 2 <p r o j e c t s > 3 <p r o v i d e r name=( providerid)> 4 <p r o j e c t name=( p r o j e c t I D )/> </provider > </p r o j e c t s > 9 <a c t o r s > 10 <o r a c l e name=( o r a c l e I D ) continueonerror=(boolean)> 11 <exclude name=(elementid)/> </o r a c l e > <t e s t a d a p t e r name=( t e s t a d a p t e r I D ) continueonerror=(boolean)> 16 <exclude name=(elementid)/> <t e s t b u n d l e name=(bundleid)> 19 <t e s t c a s e name=(classname )/> </testbundle > </t e s t a d a p t e r > </a c t o r s > 26 </c o n f i g u r a t i o n > Abbildung 4.8: Schematische Struktur einer XML-Testkonguration Erweiterung Kern des RTT-Frameworks ist die Erweiterung durch neue OSGi Dienstkomponenten für Aktoren, Repositories, Beobachter und Aktionen der Testergebnisansicht. Wie bereits im Unterkapitel 3.6 beschrieben, bestehen Dienstkomponenten aus einer Komponentenbeschreibung und einer Komponenteninstanz. Da die Komponenteninstanz durch die Dienstkomponenten-Laufzeitumgebung bereitgestellt wird, ist für die Denition einer Komponente, neben einfachen Java-Klassen und Schnittstellen, die Komponentenbeschreibung bereitzustellen. Realisiert wird eine Komponentenbeschreibung als XML- Datei. Die Auistung in Abbildung 4.9 zeigt die schematische Struktur einer Komponentenbeschreibung zur Realisierung einer RTT-Erweiterung. Zur Beschreibung einer RTT- Erweiterung muss neben der Komponenten-ID (componentid) die Implementierungsklasse (classname) ausgewiesen und die realisierten Schnittstellen (interf acename) gekennzeichnet werden. Die Namen der Implementierungsklasse und der Schnittstellen sind voll qualiziert anzugeben d.h. der Paketname ist dem Klassen- bzw. Schnittstellennamen voranzustellen. Zusätzlich kann der Anzeigenamen der Komponente über die Eigenschaft (engl. property) des Namen festgelegt werden. Auch weitere Eigenschaften können analog zum Anzeigenamen deniert werden, die dann bei der Aktivierung der Komponente auszuwerten sind. Alle Eigenschaften werden als Map von Key-Wert-Paaren an die im Attribute activate festgelegte Aktivierungsmethode übergeben. Kern der Beschreibung zur Erweiterung des RTT ist jedoch die Denition angebotener Schnittstellen, die über den Tag provide der Sektion service enthalten ist. Zur erfolgreichen Instantiierung der Implemen- 51

52 4 Implementierung 1 <s c r : component 2 xmlns : s c r="http : / /www. o s g i. org /xmlns/ s c r /v " 3 a c t i v a t e =" a c t i v a t e " 4 c o n f i g u r a t i o n p o l i c y="o p t i o n a l " 5 name=(componentid)> 6 <implementation c l a s s =(classname )/> 7 <s e r v i c e > 8 <provide i n t e r f a c e =( i n t e r f a c e n a m e )/> </ s e r v i c e > 11 <property name="name" type=" S t r i n g " value =( displayname )/> </ s c r : component> Abbildung 4.9: Schematische Struktur einer Komponentenbeschreibung zur Realisierung einer RTT-Erweiterung 1 <s c r : component 2 xmlns : s c r="http : / /www. o s g i. org /xmlns/ s c r /v " 3 a c t i v a t e =" a c t i v a t e " 4 c o n f i g u r a t i o n p o l i c y="o p t i o n a l " 5 name=(component ID)> 6 <implementation c l a s s =( c l a s s name)/> 7 <r e f e r e n c e 8 bind=(bind method ) 9 unbind=(unbind method ) 10 c a r d i n a l i t y = ( [ 0.. 1, 1.. 1, 0.. n, 1.. n ] ) 11 i n t e r f a c e =( r e q u i r e d i n t e r f a c e name) 12 /> <s e r v i c e > 15 <provide i n t e r f a c e =(provided i n t e r f a c e name)/> </ s e r v i c e > 18 <property name="name" type="s t r i n g " value=( d i s p l a y name)/> </ s c r : component> Abbildung 4.10: Erweiterte schematische Struktur einer Komponentenbeschreibung zur Realisierung einer RTT-Erweiterung tierungsklasse, durch die Dienstkomponenten-Laufzeitumgebung, muss diese alle angebotenen Schnittstellen realisieren. Neben angebotenen Schnittstellen können Dienstkomponenten auch benötigte Schnittstellen referenzieren. Die Abbildung 4.10 zeigt die erweiterte Struktur einer Komponentenbeschreibung zur Realisierung einer RTT-Erweiterung. Über den Tag ref erence wird eine benötigte Schnittstelle ausgewiesen. Die enthaltenen Attribute bind und unbind legen die Rückruf-Funktionen der Implementierungsklasse zum Binden und Lösen der geforderten Abhängigkeit fest. Die Kardinalität (engl. cardinality) der zu injizierenden Referenzen kann über das gleichnamige Attribute bestimmt werden. Eine Aktivierung der Dienstkomponente erfolgt erst, wenn die referenzierten Abhängigkeiten erfüllt werden können. In Tabelle 4.3 sind die verfügbaren Kardinalitäten und ihren Bedeutungen aufgelistet. Die hier eingeleiteten Aspekte der Komponentenbeschreibung umfassen, die zur Realisierung einer RTT-Erweiterung relevanten Bestandteile und 52

53 4 Implementierung Kardinalität Bedeutung 0..1 Eine optionale Referenz 1..1 Eine erforderliche Referenz 0..n Mehrere optionale Referenzen 1..n Mindestens eine erforderliche Referenz Tabelle 4.3: Kardinalitäten für Referenzen einer Komponenten-Beschreibung 1 Manifest Version : Bundle ManifestVersion : 2 3 Bundle ClassPath :. 4 Bundle A c t i v a t i o n P o l i c y : l a z y S e r v i c e Component : OSGI INF/ mytestadapter. xml, OSGI INF/ myoracle. xml Abbildung 4.11: Ausschnitt einer Plugin-Manifest-Datei mit Komponentenbeschreibungen beinhalten daher nur ein Untermenge der Möglichkeiten, die zur Beschreibung von Dienstkomponenten tatsächlich verfügbar sind. Eine vollständige Beschreibung, aller möglichen Bestandteile, ist der OSGi Spezikation [17] zu entnehmen. Damit die Dienstkomponenten-Laufzeitumgebung eine Komponente instantiieren kann, muss die Komponentenbeschreibung in der Metadatei (Manifest-Datei) eines Bündels bekannt gemacht werden. In der Manifest-Datei werden alle hinterlegten Komponentenbeschreibungen im Eintrag Service-Component zusammengefasst. Die Abbildung 4.11 zeigt einen Ausschnitt aus einer Manifest-Datei, die die Komponentenbeschreibungen mytestadapter.xml und myoracle.xml referenziert. Die Beschreibungen sind in diesem Beispiel im Ordner OSGI-INF, des Bündels zu hinterlegen. Seit Eclipse Version 3.5 sind Editoren und Assistenten zur Denition von Komponenten im PDE enthalten, so dass die erforderlichen Kongurationen über die graschen Oberächen vorgenommen werden können. Die verbleibenden Bestandteile zur Realisierung einer Dienstkomponente sind, die in einer Komponentenbeschreibung ausgewiesenen Schnittstellen und die Implementierungsklasse. Für RTT-Erweiterungen deniert das Framework die anzubietenden Schnittstellen und stellt Hilfsklassen zur Realisierung bereit. Die Abbildung 4.12 stellt die Schnittstellen zur Realisierung von Aktoren Orakel, Testadapter und Test-Runner in einem UML-Klassendiagramm vor. Die eingefärbten Schnittstellen, Orakel, Testadapter, Orakel-Runner und Refaktorisierungs-Test-Runner, repräsentieren die zu realisierenden Schnittstellen zur Denition der gleichnamigen Dienstkomponenten. Die Basisschnittstelle IT estactor fasst die Gemeinsamkeiten aller Aktoren zusammen. Neben Diensten zum Zugri auf Verwaltungsinformationen (z.b. Anzeigename oder ID) stellt die Schnittstelle Dienste zur Erzeugung von Zustandsinformationen (IT estactorstatef actory), zum Life-Cycle-Management (IT estactivator) und zur Bestimmung anwendbarer Programmstellen in Probanden (IElementCollector), bereit. Die Anwendung eines Aktors erfolgt 53

54 4 Implementierung Abbildung 4.12: Schnittstellen zur Realisierung von Aktoren über den Dienst apply. Die Zustandsinformationen werden zum Speichern von Zwischenergebnisse im Kontext verwendet. Über die Life-Cycle-Management-Schnittstelle werden Aktoren über das Starten bzw. Stoppen von Testläufen benachrichtigt. Mit Hilfe der Kollektoren und Filter werden anwendbare Programmstellen in Probanden ausgewählt. Die Art der ausgewählten Elemente ist Aktor-spezisch, so können in den Kollektoren von ganzen Projekten über einzelne Ressourcen bis hin zu einzelnen Programmfragmenten enthalten sein. Die Granularität wird durch das eingesetzte Modell (z.b. JDT) bestimmt. Zur Unterscheidung von syntaktischen und semantischen Orakeln erweitert die gleichnamige Schnittstelle, IOracle, die Aktor-Schnittstelle, um einen Dienst zur Abfrage des Typs. Hierdurch kann ein Orakel-Runner die korrekte Ausführungsreihenfolge sicherstellen. Auch die Schnittstelle des Testadapters, IRef actoringt estadapter, erweitert die Aktor-Schnittstelle, um einen Dienst zum Zurücksetzen von Probanden. Für denn Fall, dass das Zurücksetzen über einen Testadapter nicht möglich sein sollte, nutzt das Testwerkzeug die Dienste des Repositories, um einen Probanden in seinen Ausgangszustand zu versetzen. Insbesondere unterstützt das Framework, des RTT, Entwickler bei der Implementierung von neuen Aktoren, durch Bereitstellung von Hilfsklassen, die die gezeigten Schnittstellen realisieren. Die Abbildung 4.13 zeigt die Klassen-Hierarchie der Hilfsklassen zur Realisierung von Aktoren. Die Basis-Klasse für Orakel, Testadapter und Test-Runner implementiert die notwendigen Schnittstellen, so dass sich Sub-Klassen auf die Umsetzung der Aktor-Logik beschränken können. Die Schnittstelle zur Realisierung einer Repository-Anbindung wird in Abbildung 4.14 gezeigt. Über die gezeigte Schnittstelle stehen Dienste zur Synchronisation, zum Abrufen und Identizieren von Probanden zur Verfügung. Des Weiteren deniert die Schnittstelle einen Dienst, mit dem ein Probanden-Projekt in seinen Ausgangszustand versetzen werden kann. Auf Basis der Team-Integration vereinfacht sich die Implementierung, durch Ableitung von der abstrakten Klasse T eamrepository, auf die Realisierung der Dienste 54

55 4 Implementierung Abbildung 4.13: Hilfsklassen zur Realisierung von Aktoren Abbildung 4.14: Schnittstelle zur Anbindung eines Repositories 55

56 4 Implementierung Abbildung 4.15: Schnittstellen und Klassen zur Realisierung einer Modell-Beobachter-- Komponente revertchanges und ref reshlocal. Zum Hinzufügen und Verwalten von Probanden werden im Rahmen des RTT die bereitgestellten Mittel der Team-Integration (z.b. Team- SVN) verwendet, so dass diese Schnittstelle auf Denition dieser Dienste verzichtet. Zur Ankopplung von Analysewerkzeugen kommt das Beobachter-Entwurfsmuster (engl. observer-pattern), aus [16], zum Einsatz. Die Abbildung 4.15 zeigt die Denition der umgesetzten Schnittstellen und Klassen im Framework. Die Schnittstellen IObserver und IObservable sind generisch deniert, so dass über die Vorlageparameter eine Typisierung erfolgen kann anders als in der Standard-Implementierung der Java-Bibliothek umgesetzt. Eine Basis-Implementierung für beobachtbare (engl. observable) Objekte oder Subjekte (engl. subject) beinhalten die Klassen Subject und SubjectAdapter. Die Umsetzung eines Subjektes kann durch Ableitung von der Klasse Subject realisiert werden. Ist die Ableitung, Aufgrund einer bereits bestehenden Hierarchie, nicht möglich, kann durch Komposition mit einem Subjekt-Adapter die Umsetzung erfolgen. Die Dienstschnittstelle zur Realisierung einer Modell-Beobachter-Komponente wird durch die Schnittstelle IT estrunlistener gestellt. Diese bindet die Vorlageparameter der Basisschnittstelle IObserver an die Schnittstellen und Klassen IT estrunlistener (Beobachter), T estrootrunsession (Subject) und T estrunevent (Argument). Das Ereignisargument 56

57 4 Implementierung Abbildung 4.16: Schnittstelle zur Realisierung einer Aktion für die Testergebnisansicht (T estrunevent) kennzeichnet die Art der Modelländerungen (gestartet, beendet oder zurückgesetzt) und das beteiligte Modellelement. Da Beobachter-Komponenten nicht explizit registriert werden, sondern implizit durch den Anwendungskern, übernimmt dieser auch die Deregistrierung. Um dennoch Speicherlöcher zu vermeiden, werden Beobachter durch Subjekte nur schwach 3 (engl. weak) referenziert d.h. existieren im System keine starken Referenzen auf einen Beobachter, wird dieser von der automatischen Speicherbereinigung (GC) freigegeben (auch ohne Deregistrierung). Abschlieÿend kann der RTT um neue Kontext-Menü-Einträge (Aktionen) für die Testergebnisansicht erweitert werden, dazu ist die Realisierung der Dienstkomponenten-Schnittstelle IActionAdapter notwendig. Die Denition dieser Schnittstelle ist in der Abbildung 4.16 gezeigt. Die Selektionen von Modellelementen in der Testergebnisansicht werden an die Dienste isapplicable und gett arget delegiert. Über den Dienst isapplicable werden die anwendbaren Aktionen geltert. Der Dienst gett arget liefert eine auszuführende Aktion auf Basis der JFace-Schnittstelle IAction. 4.3 Benutzerinterface Der Refactoring Tool Testers ist als entwicklungsbegleitendes Testwerkzeug entworfen. Die Benutzung ist der JUnit-Eclipse-Integration, durch die JDT, nachempfunden, so dass sich Entwickler, die bereits Erfahrungen mit JUnit-Plugin-Tests vorweisen können, ohne lange Einarbeitungszeit im RTT zurechtnden. Neben der Installation des RTT, sind die Schritte zur Erzeugung von Testprojekten, Kongurationen und zum Starten und Debuggen von Testläufen im Anhang B beschrieben. Dieses Kapitel beschränkt sich daher auf die Beschreibung der bereitgestellten Mittel zur Analyse von Testläufen der Testergebnisansicht. 3 Alle Objekt-Referenzen sind in Java starke Referenzen, schwache Referenzen werden durch die Klasse W eakref erence repräsentiert. Neben diesen unterscheidet Java noch Sof tref erence und P hantomref erence, die jedoch für die RTT Implementierung nicht relevant sind.[21] 57

58 4 Implementierung Zur Isolation von Tests wird ein Testlauf in einer neuen Eclipse-Instanz gestartet. Während des Testlaufs sind Benutzerinteraktionen durch ein modales Fortschrittsfenster gesperrt. Der gesamte Testlauf kann jeder Zeit durch den Benutzer abgebrochen und erneut gestartet werden. Nach Abschluss eines Testlaufs stehen die Ergebnisse in der Testergebnisansicht, RTT Result Navigator, zur Verfügung. In der ersten Zeile der Anzeige wird der Status des gesamten Testlaufs dargestellt, der sich aus den einzelnen Einträgen der Anzeige zusammensetzt. Die Spalten der Ansicht, aus Abbildung 4.17, beschreiben: Abbildung 4.17: Testergebnisansicht Label den Testfall des Refaktorisierungswerkzeug ggf. mit den verwendeten Refaktorisierungsparametern, Time die Durchlaufzeit der Ausführung, Progress-State den Verarbeitungszustand, wie beispielsweise ST OP P ED, RU N N IN G oder COMP LET ED, Result das Verarbeitungsergebnis, wie z.b. OK, ERROR oder F AILU RE. Diese wird am Anfang der Zeile symbolisch repräsentiert. Zu Beachten ist, dass auch Ausnahmefehler, ausgelöst durch JUnit-Testfälle, durch ERROR gekennzeichnet werden, 58

59 4 Implementierung Class die Klasse des zugrunde liegenden Modellelements, Run-Stage das Ausführungsstadium, wie z.b. Initialisierung oder Ausführung, des Modellelement bzw. die Verarbeitungsphase in der es erzeugt wurde. Des Weiteren stellt die Ansicht zur Analyse, in der Toolbar, Filter zur Verfügungen, über die die Anzeige eingeschränkt oder erweitert werden kann. Die Abbildung 4.18 zeigt die verfügbaren Filtereinstellungen. Einträge die in der Initialisierungsphase eines Aktors erzeugt werden, sind standardmäÿig ausgeblendet. Im Fehlerfall werden diese Einträge, trotz aktiver Filtereinstellung (verbergen der Initialisierung), angezeigt. Zur Repräsenta- Abbildung 4.18: Filter der Testergebnisansicht tion von zusammengesetzten Testergebnissen ist die Anzeige strukturiert gewählt. Durch Aufklappen eines Eintrags können die Details begutachtet werden, wie z.b. der Status der Orakel-Überprüfungen, die Eingaben und Ausgaben des Testfalls oder die modizierten Ressourcen. Einträge die Fehler aufweisen werden beim Expandieren automatisch bis zur Fehlerquelle erweitert. Über die Option Auto-Expand, des Toolbar-Menüs, können Einträge grundsätzlich vollständig erweitert werden. Jedes der Elemente der Anzeige ist durch ein Modellelement repräsentiert. Einigen Modellelementen sind über das Kontextmenü Aktionen zugeordnet: T estrootcontext oder Ref actoringt estelement erneutes Anwenden, der durch einen Testfall erzeugten Refaktorisierungsbeschreibung (für den Fall, dass diese ausgeführt wurde). Vor Anwendung werden die beteiligten Probanden-Projekte in ihren Ausgangszustand versetzt, 59

60 4 Implementierung JavaT estelement önen eines JDT-Modellelements im Editor, DiffT estelement önen einer Ressource im Editor. Änderungen werden nur sichtbar, wenn die Refaktorisierung erneut ausgeführt wurde, JU nitt estcaseelement önen eines JUnit-Testfalls im Editor und Ausgabe des JUnit-Exception-Stack-Trace in der Konsole, JavaCompileP roblem önen der Fehler-Quelle im Editor, ExceptionT estelement Ausgabe des Exception-Stack-Trace in der Konsole. Des Weiteren können die Ergebnisse der Ansicht in einer Datei, in Komma-separiertem (CSV) Format, gespeichert werden. Die angewendeten Filter werden beim Exportieren berücksichtigt. 60

61 5 Diskussion 5.1 Interpretation und Bewertung Mit dem Refactoring Tool Tester aus dieser Arbeit steht eine Referenzimplementierung für das automatisierte Testen von Java-Refaktorisierungswerkzeugen in Eclipse zur Verfügung. Das Testwerkzeug verwendet dazu quelloene Programme (Probanden) als Testeingaben für Refaktorisierungswerkzeuge. Das Aufdecken von Fehlern übernehmen im Rahmen des Testens Orakel, die hierzu Probanden einer syntaktischen und semantischen Überprüfung unterziehen. Ein Vorteil des Einsatzes von quelloenen Programmen ist, dass es sich bei diesen um reale Anwendungen handelt, die eine Vielzahl der von den Anwendern verwendeten Sprachkonstrukten beinhalten und damit repräsentativ sind. Ein weiterer Vorteil ist, dass viele quelloene Programme eine hohe Testabdeckung in Form von Regressionstests (à la JUnit) beinhalten, die zur semantischen Prüfung herangezogen werden können. Nachteilig ist jedoch, dass Regressionstests, als Teil der Probanden, indirekt refaktorisiert werden, wodurch der Vergleich vor und nach Refaktorisierung ggf. nicht auf der gleichen Testbasis beruht. Dabei besteht die Gefahr, dass durch fehlerhafte Refaktorisierungen, Fehler in Regressionstests eingeführt werden, die dann Fehler in Refaktorisierungswerkzeugen verdecken. Kern der Implementierung des RTT ist die Umsetzung als Framework für das automatisierte Testen von Refaktorisierungswerkzeugen. Dabei ist das Framework nicht auf eine Programmiersprache (z.b. Java) beschränkt, sondern deniert Schnittstellen sprachund technologieunabhängig und organisiert Implementierungsabhängigkeiten (z.b. JDT) in zentralen Paketen. Insbesondere ermöglicht die Umsetzung als Framework die Analysefähigkeiten des RTT, durch Bereitstellung von Dienstkomponenten, zu erweitern beispielsweise durch Orakel. Der deklarative Dienstansatz, des OSGi-Komponentenmodells, erlaubt auf elegante Weise der Dynamik des OSGi-Frameworks gerecht zu werden und bieten dabei den Vorteil, dass Komponenten, als einfache Java Objekte, isoliert getestet werden können. Trotzdem kommt die Umsetzung nicht ohne den imperativen Ansatz (durch Verwendung von ServiceTracker) aus, um Dienstkomponenten auÿerhalb der Komponenten-Deklaration verfügbar zu machen. Hintergrund ist, dass die meisten Eclipse-Plugins immer noch keine Dienste anbieten, sondern Erweiterungspunkte bereitstellen, wodurch ein Teil der Eleganz wieder verloren geht. Da der deklarative Dienstansatz Komponentenbeschreibungen zur Denition von Dienstkomponenten verwendet, besteht die Problematik Beschreibungen und Implementierung konsistent zu halten. Durch Refaktorisierungen, wie z.b. Rename einer Implementierungsklasse können Inkonsistenzen 61

62 5 Diskussion entstehen entsprechende Refaktorisierungswerkzeuge zur Konsistenzerhaltung fehlen in der Eclipse Version 3.5 und 3.6. Des Weiteren verwendet der RTT Contract4J zur Spezikation und Überprüfung von Invarianten, Vor- und Nachbedingungen nach Designby-Contract (DbC). Aufgrund einer starken Verschlechterung der Performance und Erhöhung des Speicherverbrauches, durch Einsatz von Contract4J, konnte dieser Ansatz nicht durchgehalten werden, so dass die umgesetzten Verhaltensspezikationen eher der Dokumentation dienen. Im Bezug auf die Kernfunktionalität des RTT, das automatisierte Testen von Refaktorisierungswerkzeugen, konnten durch Bereitstellung deklarativer Testadapter, die Anbindung von Refaktorisierungswerkzeugen stark vereinfacht werden. Dabei beinhalten weder Testfälle für Refaktorisierungswerkzeuge noch Testadapter Annahmen zum Erfolg oder Misserfolg einer Refaktorisierung diese werden alleine durch Orakel qualiziert. Wird ein Fehler durch einen Testfall für ein Refaktorisierungswerkzeug aufgedeckt, führt dies zum Abbruch seiner Ausführung d.h. der RTT wechselt zum nächsten Testfall. Zu Berücksichtigen ist deshalb für Testfälle, anders als bei Testadaptern, dass diese nur ein einzelnes Szenario beinhalten sollten. Bei Beachtung dieses Grundsatzes reduziert sich die Laufzeit von Tests, ohne dass weitere Szenarien unberücksichtigt bleiben. Der Abfragewerkzeug-Testadapter bietet zudem die Möglichkeit anwendbare Programmstellen, durch Formulierung von Abfragen auf Basis von JQuery auszuwählen und begegnet damit der Problemstellung der Auswahl geeigneter Refaktorisierungsparameter. Vorteil des Einsatzes von Abfragewerkzeugen ist die Ausdrucksstärke bei der Formulierung von Beziehungen zwischen Programmelementen, die sonst nur schwierig durch Einsatz der JDT-Search-Engine, dem JDT-Modell und das Durchlaufen der ASTs herauszultern sind. Anderseits birgt der Einsatz von Abfragen zur Auswahl von anwendbaren Programmstellen die Gefahr, dass die Auswahl zu spezisch gewählt wird, so dass nur noch Randfälle durch die formulierten Tests berücksichtigt werden und damit der Vorteil des Einsatzes quelloener Probanden-Projekte verloren geht für den Fall, dass diese nicht die geforderten Sprachkonstrukte enthalten. Daher ist die Ausgewogenheit zwischen geeigneten Abfragen und verwendeten Probanden-Projekten für die Faktoren Testlaufzeit und -abdeckung entscheidend. Auch ist der Einsatz von JQuery als Abfragewerkzeug nur bedingt von Nutzen, da Abfrageergebnisse auf Basis des JDT-Modells gebunden werden, so dass das Durchlaufen der AST nicht ausbleibt, um eine feiner Granularität zu erreichen (z.b. zur Auswahl von Kontrollussanweisungen oder lokalen Variablen in Methoden). Des Weiteren ist die Art der Deklaration von Abfragen, als Text in Annotationen, fehleranfällig, da diese keinen Gültigkeitsüberprüfungen durch einen Übersetzer unterzogen werden. Dem Benutzer steht jedoch die Möglichkeit zur Verfügung die Abfragen in der Benutzerschnittstelle des Abfragewerkzeuges (z.b. JQuery) zu testen. Eine Weitere Fehlerquelle ist jedoch das Binden von Abfrageergebnissen an Test-Methoden-Argumente (durch Annotationen), die zu Ausnahmefehlern führen kann, wenn die gewählten Datentypen nicht zuweisungskompatibel zu den Modellelementen der Abfrageergebnisse sind. Im Rahmen des Testens können jedoch Laufzeitfehler toleriert werden, da diese lediglich zum Fehlschlag eines Tests führen und in diesem Zusammenhang behoben werden können. 62

63 5 Diskussion Als entwicklungsbegleitendes Testwerkzeug ist der RTT, der Benutzung der JUnit-Eclipse- Integration, durch die JDT, nachempfunden. Zentrales Merkmal ist, dass Tests isoliert, in einer neuen Eclipse-Instanz, ausgeführt werden, so dass die produktive Umgebung von Instabilitäten zu testender Refaktorisierungswerkzeuge unbeeinusst bleibt. Ein weiterer Vorteil, der sich durch die Trennung ergibt, ist, dass Tests und Refaktorisierungswerkzeuge zusammen mit dem RTT Framework gedebuggt werden können was die Fehlersuche in allen beteiligten Plugins vereinfacht. Des Weiteren stellt der RTT Mittel zur Analyse von Fehler zur Verfügung, so stehen neben Informationen zur Refaktorisierung (z.b. Refaktorisierungsparameter oder -beschreibung) Aktionen zum Nachstellen des Fehlerbildes (z.b. Wiederholen einer Refaktorisierung) zur Verfügung. Das Herausnden der Fehlerursache ist jedoch manuelle Aufgabe des Testentwicklers. 5.2 Vergleich mit verwandten Arbeiten Da die Idee des automatisierten Testens von Refaktorisierungswerkzeugen nicht neu ist, existieren Testwerkzeuge, die bereits erfolgreich Fehler in den Eclipse- und NetBeanseigenen Refaktorisierungswerkzeugen nachgewiesen haben [6]. Zur Abgrenzung zur vorliegenden Arbeit werden die zugrunde liegenden Konzepte, des ASTGen [2] und SafeRefactor [24][23], mit denen des RTT verglichen. Kernkonzept des ASTGen ist die Generierung von Probanden (Quellcode) für Refaktorisierungswerkzeuge. Hierzu schreiben Tester Generatoren, die die Generierung übernehmen. Zu diesem Zweck ist der ASTGen als Bibliothek von generischen, wiederverwendbaren und kombinierbaren Generatoren geschrieben, die abstrakte Syntaxbäume erzeugen. Zur syntaktischen Überprüfung kommt der Übersetzer der integrierten Entwicklungsumgebung, als Orakel, zum Einsatz. Die semantischen Überprüfungen erfolgen durch Anwendung von diversizierenden Tests. Zum diversizierenden Testen werden die generierten ASTs der gleichen Refaktorisierungen in Eclipse und NetBeans unterzogen und die Ausgaben miteinander verglichen Abweichung nach Refaktorisierung, durch die unterschiedlich implementierten Refaktorisierungswerkzeuge, deuten auf Fehler hin. Der Tester muss im Anschluss feststellen welches oder welche Refaktorisierungswerkzeuge Fehler eingebracht haben. Des Weiteren wendet ein invertierendes Orakel Gegen-Refaktorisierung zu einer Refaktorisierung an, um Änderungen rückgängig zu machen und vergleicht im Anschluss diese Version mit der Originalen, um Fehler aufzudecken [2]. Der SafeRefactor ist als Adapter für Refaktorisierungswerkzeuge entworfen und arbeitet daher direkt auf den produktiven Quellen von Anwendern. Auch beim SafeRefactor kommt der Übersetzer, der integrierten Entwicklungsumgebung, zur syntaktischen Überprüfung zum Einsatz. Zur semantischen Überprüfung wendet das Werkzeug JUnit-Testfälle an. Jedoch kommt SafeRefactor ohne die Bereitstellung von Testfällen durch den Benutzer aus, denn diese werden automatisch generiert. Hierzu analysiert das Werkzeug alle zu refaktorisierenden Programmstellen und identiziert die Methoden, die nicht von der Refaktorisierung betroen sind. Für die identizierten Methoden, die beide Versionen (vor 63

64 5 Diskussion Werkzeug Testeingaben für Testverfahren zur Wiederhol- Refaktorisierungs- semantischen barkeit von werkzeuge Überprüfung Tests ASTGen automatisch generierte AST diversizierenden Tests automatisch Safe- Quellen produktiver automatisch generierte manuell Refactor Programme Regressionstests RTT quelloene Programme enthaltene Regressionstests automatisch Tabelle 5.1: Gegenüberstellung der Werkzeuge ASTGen, SafeRefactor und RTT und nach Refaktorisierung) gemeinsam haben, wählt das Werkzeug zufällig geeignete Testeingaben aus und bestimmt die Ausgaben. Die so erzeugten Eingaben werden zusammen mit den erwarteten Ausgaben in JUnit-Testfällen festgehalten. Insbesondere nimmt sich das Werkzeug damit der Problemstellung, die gleiche Testbasis vor und nach Refaktorisierung zu verwenden, an [24]. Zum RTT unterscheiden sich die vorgestellten Werkzeuge in den funktionalen Aspekten, verwendete Testeingaben, verwendete Testverfahren (zur semantischen Überprüfung) und der Wiederholbarkeit von Tests. Die Tabelle 5.1 zeigt, in einer Gegenüberstellung, die Unterschiede in den genannten Aspekten zwischen dem ASTGen, SafeRefactor und dem RTT. 64

65 6 Schlussbetrachtungen 6.1 Zusammenfassung und Fazit Heutige Entwicklungsumgebungen, wie z.b. Eclipse, NetBeans oder Visual-Studio, bieten Werkzeugunterstützung zur automatisierten Anwendung von Refaktorisierungen an. Viele der existierenden Refaktorisierungswerkzeuge bleiben jedoch hinter den gestellten Erwartungen, so dass diese nicht korrekt Arbeiten und Fehler einführen [25]. Die Fehler, die dabei durch Anwendung von Refaktorisierungswerkzeugen in ein Programm eingeführt werden, reichen von Übersetzungsfehlern bis hin zu Verhaltensänderungen, die bestenfalls im Zuge des Testens aufgedeckt werden oder gänzlich unentdeckt bleiben. Jedenfalls wird das Aufdecken von Fehlern den Benutzer der Refaktorisierungswerkzeuge überlassen. Um jedoch die Qualität von Refaktorisierungswerkzeugen nachhaltig zu verbessern, bietet sich, wie für andere Programme auch, das Testen an. Mit dem Refactoring Tool Tester aus dieser Arbeit steht eine Referenzimplementierung für das automatisierte Testen von Java-Refaktorisierungswerkzeugen in Eclipse zur Verfügung. Durch dieses Testwerkzeug können damit Fehler in Refaktorisierungswerkzeugen, mit vertretbarem Aufwand, aufgedeckt werden. Die zum Testen notwendigen repräsentativen Beispielprogramme (Probanden) und Regressionstests werden durch die Bereitstellung quelloener Programme abgedeckt. Diese dienen Refaktorisierungswerkzeugen, im Rahmen des Testens, als Eingaben. Zudem nutzt der RTT die enthaltenen Regressionstests zur semantischen Überprüfungen von Probanden nach Durchführung von Refaktorisierungen und ist damit in der Lage ggf. eingebracht Verhaltensänderungen aufzudecken. Um eine Testkonstellation im Nachhinein auch wiederholen zu können, verwaltet der RTT Probanden und Kongurationen in Repositories. Mit der Umsetzung als Framework für Refaktorisierungs-Testwerkzeuge erreicht der RTT die Erweiterbarkeit seiner Analysefähigkeiten. Dazu weist der RTT eine komponentenbasierte Architektur auf, die dem OSGi- Komponentenmodell unterliegt. Auf dieser Basis erfolgt für den RTT die Anbindung von zu testenden Refaktorisierungswerkzeugen mittels Testadaptern. Des Weiteren konnte der RTT durch Bereitstellung deklarativer Testadapter die Anbindung von Refaktorisierungswerkzeugen stark vereinfachen. Um Tester letztendlich noch bei Auswahl geeigneter Refaktorisierungsparameter zu unterstützten, beinhaltet der RTT die Anbindung des Abfragewerkzeugs JQuery, das es Testern ermöglicht eine Auswahl von Programmstellen in Abfragen zu formulieren. Als entwicklungsbegleitendes Testwerkzeug ist der RTT, der Benutzung der JUnit-Eclipse- Integration, durch die JDT, nachempfunden. Zentrales Merkmal ist, dass Tests isoliert, 65

66 6 Schlussbetrachtungen in einer neuen Eclipse-Instanz, ausgeführt werden, so dass die produktive Umgebung von Instabilitäten zu testender Refaktorisierungswerkzeuge unbeeinusst bleibt. Ein weiterer Vorteil, der sich durch die Trennung ergibt, ist, dass Tests und Refaktorisierungswerkzeuge zusammen mit dem RTT Framework gedebuggt werden können was die Fehlersuche in allen beteiligten Plugins vereinfacht. Zur Evaluation der Ergebnisse, dieser Arbeit, werden die JDT-eigenen Refaktorisierungswerkzeuge, im Rahmen einer parallelen Arbeit [9], mit dem umgesetzten Testwerkzeug untersucht. 6.2 Ausblick Die vom RTT bereitgestellten Mittel erönen die Möglichkeit zur Anbindung zukünftiger Testwerkzeuge. So könnten beispielsweise Werkzeuge zur automatischen Fehlerlokalisierung, z.b. EZUnit [10] oder Delta-Debugging [1], angebunden werden, um Tester bei der Bestimmung von Fehlerursachen zu unterstützen. Auch die Anbindung des Testwerkzeuges, SafeRefactor [24], kann die Fähigkeiten des RTT bereichern, da dieser es erlauben würde Probanden mit keiner oder einer geringen Testabdeckung zum Testen zu verwenden ohne auf semantische Überprüfungen verzichten zu müssen. Des Weiteren würde der RTT für den SafeRefactor eine Testumgebung bereitstellen können, in der Tests wiederholbar sind. Zur Ankopplung könnte beispielsweise ein deklarativer Testadapter umgesetzt werden. Grundsätzlich bietet der Einsatz von Abfragewerkzeugen für das Testen und die Entwicklung von Refaktorisierungswerkzeugen Vorteile, die nicht von der Hand zuweisen sind, wie z.b. die Ausdrucksstärke bei der Auswahl von Programmstellen, die mit den verfügbaren Mitteln (z.b. JDT-Modell, AST oder -Search-Engine) sonst nur schwierig umzusetzen sind (bedenkt man, dass in den Abfragen Beziehungen zwischen Programmelementen ausgedrückt werden können). Trotzdem ist der Einsatz von JQuery als Abfragewerkzeug nur bedingt von Nutzen, da Abfrageergebnisse auf Basis des JDT-Modells gebunden werden, so dass das Durchlaufen der AST nicht ausbleibt, um eine feiner Granularität zu erreichen (z.b. zur Auswahl von Kontrollussanweisungen oder lokalen Variablen in Methoden). Von daher wäre entweder die Erweiterung von JQuery oder die Evaluation anderer Abfragewerkzeuge interessant, wie beispielsweise SemmleCode [33]. Des Weiteren ist die Art der Deklaration von Abfragen, als Text in Annotationen, fehleranfällig, da diese keinen Gültigkeitsüberprüfungen durch einen Übersetzer unterzogen werden. Eine Weitere Fehlerquelle ist zudem das Binden von Abfrageergebnissen an Test- Methoden-Argumente (durch Annotationen), die zu Ausnahmefehlern führen kann, wenn die gewählten Datentypen nicht zuweisungskompatibel zu den Modellelementen der Abfrageergebnisse sind. Durch Einsatz bzw. die Denition einer Domain-spezischen Sprache (DSL) könnten diese Probleme angegangen werden. 66

67 Literaturverzeichnis [1] Cleve, H. ; Zeller, A.: Locating causes of program failures. In: Software Engineering, ICSE Proceedings 27 (2005), S [2] Daniel, B. ; Dig, D. ; Garcia, K. ; Marinov, D.: Automated Testing of Refactoring Engines. In: ESEC-FSE Proceedings 6 (2007), S [3] De Volder, K.: JQuery: A generic code browser with a declarative conguration language. In: Practical Aspects of Declarative Languages (2006), S [4] eclipse.org (Veranst.): Eclipse IDE for Java Developers, Release Galileo. Juni URL [5] Fowler, M. ; Beck, K.: Refactoring: improving the design of existing code. Addison- Wesley Professional, 1999 [6] Garcia, K.M.: TESTING THE REFACTORING ENGINE OF THE NETBEANS IDE. In: Masterarbeit University of Illinois at Urbana-Champaign (2007) [7] Griffel, F.: Componentware-Konzepte und Techniken eines Softwareparadigmas. In: Heidelberg: dpunkt-verlag (1998) [8] Gruber, O. ; Hargrave, BJ ; McAffer, J. ; Rapicault, P. ; Watson, T.: The Eclipse 3.0 platform: adopting OSGi technology. In: IBM Systems Journal 44 (2005), Nr. 2, S [9] Ikkert, Sergei: Untersuchung der Eclipse-JDT-Refaktorisierungen mit Hilfe des Refactoring Tool Testers. In: Masterarbeit Fernuniversität in Hagen (2010) [10] Krinke, J. ; Meyer, N. ; Steimann, F.: EZUNIT: A Framework for Associating Failed Unit Tests with Potential Programming Errors. In: XP Conference 8 (2007), Nr. 1.15, S [11] Lammert, Rainer: Component Frameworks. In: Seminar, Komponentenbasierte Programmierung Fernuniversität in Hagen (2008) [12] Lau, Kung-Kiu ; Wang, Zheng: Software Component Models. In: IEEE TRANS- ACTIONS ON SOFTWARE ENGINEERING 33, NO. 10 (2007) [13] Levonyak, Markus: OSGi als Grundlage für komponentenbasierte Programmierung. In: Seminar, Komponentenbasierte Programmierung Fernuniversität in Hagen (2010) [14] Liggesmeyer, P.: Software-Qualität. Spektrum, Akad. Verl., 2002 [15] Mansfeld, A.: Realisierung von Software-Produktlinien mit der Eclipse Rich-Client- Platform. In: Diplomarbeit Fachhochschule Giessen-Friedberg (2006) 67

68 Literaturverzeichnis [16] Naftalin, M. ; Wadler, P.: Java generics and collections. O'Reilly Media, Inc., 2006 [17] OSGi Alliance (Veranst.): OSGi Service Platform Release 4 Version 4.2 Compendium Specication URL [18] OSGi Alliance (Veranst.): OSGi Service Platform Release 4 Version 4.2 Core Speci- cation URL [19] Polarion (Veranst.): Subversive, Subversion Team Provider for Eclipse. Juni URL [20] Radziwonowicz, L. ; Pavlov, R. ; Zmuda, R. ; Ziebell, S.: Unit Testing mit JUnit. In: Ausarbeitung, Methoden und Werkzeuge in der Softwareentwicklung WS0607 (2007). URL ausarbeitungen/ausarbeitung-3.pdf [21] Reichel, Peter: Realisierung einer integrierten Speicherverwaltung mit der Unterstützung schwacher Referenzen für den Prozessor SHAP, TECHNISCHE UNIVER- SITÄT DRESDEN FAKULTÄT INFORMATIK, Diplomarbeit, 2008 [22] Shavor, S. ; Fairbrother, S. ; D'Anjou, J. ; Kehn, D.: Eclipse. Anwendungen und Plug-Ins mit Java entwickeln. Addison-Wesley, München, 2004 [23] Soares, G. ; Cavalcanti, D. ; Gheyi, R. ; Massoni, T. ; Serey, D. ; Cornélio, M.: SAFEREFACTORTool for Checking Refactoring Safety. [24] Soares, G. ; Gheyi, R. ; Serey, D. ; Massoni, T.: Making program refactoring safer. In: IEEE Software (2010) [25] Steimann, F.: Korrekte Refaktorisierungen: Der Bau von Refaktorisierungswerkzeugen als eigenständige Disziplin. In: OBJEKTspektrum 4 (2010), S URL os/2010/04/steimann_os_04_10.pdf [26] Steimann, F. ; Keller, D. ; Aziz Safi, B.: Moderne Programmiertechniken und -methoden. In: Vorlesungsskript Fernuniversität in Hagen (2007) [27] Szurszewski, J.: We Have Lift-o: The Launching Framework in Eclipse. In: Eclipse Corner Articles (2003). URL [28] Szyperski, C. ; Bosch, J. ; Weck, W.: Component-oriented programming. In: Object-Oriented Technology ECOOP99 Workshop Reader Springer (Veranst.), 1999, S [29] Tavares, A.L.C. ; Valente, M.T.: A gentle introduction to OSGi. In: ACM SIGSOFT Software Engineering Notes 33 (2008), Nr. 5, S. 15 [30] Tigris.org (Veranst.): TortoiseSVN is an easy-to-use SCM / source control software for Microsoft Windows. Juni URL [31] ubuntu.com (Veranst.): Ubuntu Subversion Installationhinweise. Juni URL 68

69 Literaturverzeichnis [32] University of British Columbia (Veranst.): JQuery, a query-based code browser Installationshinweise. Juni URL installation.html [33] Verbaere, M. ; Hajiyev, E. ; De Moor, O.: Improve software quality with SemmleCode: an eclipse plugin for semantic code search. In: Conference on Object Oriented Programming Systems Languages and Applications 22 (2007), S [34] Walther, T.: Architektur und Konzepte von Eclipse 3. In: Diplomarbeit Freie Universität Berlin (2005) [35] Weyerhäuser, M.: Die Programmierumgebung Eclipse. In: JavaSpektrum CeBIT- Sonderausgabe (2003) 69

70 A Paketstruktur Die beschriebene Organisation, aus dem gleichnamigen Unterkapitel 4.1, des RTT ist in den nachfolgenden Paketen realisiert. Die Tabellen A.2, A.4 und A.6 stellen die Pakete vor und beschreiben die enthaltenen Programmelemente. Beschreibung stellt Annotationen und Klassen zur Formulierung von Testfällen für Refaktorisierungswerkzeuge bereit. beinhaltet die Basisschnittstellen des Testwerkzeugs, die beispielsweise das Modell, die Aktoren, die Testkonguration, die Test-Runner und -Beobachter auszeichnen. Neben diesen Bestandteilen stellt das Pakete die Fassade, RTTCore, zum Zugri auf Dienste-Komponenten, auÿerhalb der Komponenten-Deklaration, bereit. kapselt die Klassen-Hierarchie der Aktor-unabhängigen Modellelemente. stellt Klassen zur Verwaltung und Implementierung von Orakeln, als Dienstkomponenten, bereit. beinhaltet die Basisschnittstellen und Klassen des Test- werkzeugs zur Denition und Verwaltung von Repositories, als Dienstkomponenten. stellt Klassen zur Verwaltung und Implementierung von Repositories auf Basis der Team-Integration bereit. Paketname de.fernunihagen.rtt de.fernunihagen.rtt. framework de.fernunihagen.rtt. framework.model de.fernunihagen.rtt. framework.oracle de.fernunihagen.rtt. framework.repository de.fernunihagen.rtt. framework.repository. team de.fernunihagen.rtt. framework.repository. team.svn de.fernunihagen.rtt. framework.repository. team.svn.internal de.fernunihagen.rtt. framework.testadapter liefert die Dienstkomponente zur Ankopplung an ein Team-SVN-Repository, unter Verwendung von Subversive. beinhaltet den Bündel-Aktivator des SVN Konnektor Plugins. stellt Klassen zur Verwaltung und Implementierung von Testadaptern, als Dienstkomponenten, bereit. Tabelle A.2: Übersicht der RTT Paketstruktur Teil 1 70

71 A Paketstruktur enthält die Dienstkomponente des deklarativen Abfrage- werkzeug-testadapter auf Basis von JQuery. Beinhaltet den Bündel-Aktivator des JQuery-Testadapter-Plugins. beinhaltet den Bündel-Aktivator des UI-Plugins. Paketname de.fernunihagen.rtt. framework.util de.fernunihagen.rtt. internal de.fernunihagen.rtt. internal.lter de.fernunihagen.rtt. internal.jdt de.fernunihagen.rtt. internal.jdt.oracle de.fernunihagen.rtt. internal.runtime de.fernunihagen.rtt. internal.testadapter de.fernunihagen.rtt. internal.util de.fernunihagen.rtt. ui de.fernunihagen.rtt. ui.app de.fernunihagen.rtt. ui.app.internal de.fernunihagen.rtt. ui.testadapter.jquery. internal de.fernunihagen.rtt. ui.internal Beschreibung beinhaltet Schnittstellen und Hilfsklassen, die Paket- übergreifend Verwendung nden und von der Benutzerschnittstelle unabhängig sind. beinhaltet den Bündel-Aktivator des Core-Plugins. stellt die Klassen-Hierarchie der JDT-unabhängigen Filter zur Verfügung. kapselt Implementierung für Hilfsklassen und Modellele- mente auf Basis der JDT, beispielsweise Klassen zum Suchen und Filtern von anwendbaren Programmstellen und Starten von JUnit4-Testläufen. liefert die Dienstkomponenten für das syntaktische und semantische Orakel auf Basis der JDT. beinhaltet die Implementierungen der Koordinationslogik, so z.b. den Anwendungskern oder die Dienstkomponenten der Test-Runner (Orakel-Runner und Refaktorisierungs-Test-Runner). stellt die Klassen-Hierarchie der Testschritte (Test- ProcedureStep) für deklarative Testadapter bereit. beinhaltet alle Implementierungen von der Benutzer- schnittstelle unabhängiger Hilfsklassen, die von den JDT unabhängig sind. stellt Basisschnittstellen zur Denition von Dienstkompo- nenten, zur Erweiterung der Oberächen, bereit. Beinhaltet die Fassade, RTTCoreUI, zum Zugri auf Dienste- Komponenten, auÿerhalb der Komponenten-Deklaration. beinhaltet den Prüfstand (engl. test bench), der vom Launcher verwendet wird, um Tests isoliert auszuführen. Des Weiteren stellt das Pakete die Implementierung der Launch-Konguration und des Launchers (Launch- Delegate) zur Verfügung. beinhaltet den Bündel-Aktivator des Testbench-Plugins. Tabelle A.4: Übersicht der RTT Paketstruktur Teil 2 71

72 A Paketstruktur Beschreibung enthält Implementierungen für JDT-unabhängige Aktionen, als Dienstkomponenten, zur Erweiterung der Analyse- Fähigkeiten der Oberäche, z.b. Wiederholen einer Refaktorisierung. beinhaltet Implementierungen von Hilfsklassen und Aktionen, als Dienstkomponenten, auf Basis der JDT. beinhaltet die Oberächen (Ansichten und Assistenten) der Test- bzw. Launch-Konguration. stellt eine Implementierungen für einen deklarativen Java-Testadapter (ohne Abfragewerkzeug) bereit. beinhaltet Schnittstellen und Hilfsklassen, die Paket- übergreifend Verwendung nden und von der Benutzerschnittstelle abhängig sind. kapselt die Implementierung der Testergebnis-Ansicht. Paketname de.fernunihagen.rtt. ui.internal.action de.fernunihagen.rtt. ui.internal.jdt de.fernunihagen.rtt. ui.internal.jdt.launcher de.fernunihagen.rtt. ui.internal.jdt.testadapter de.fernunihagen.rtt. ui.internal.util de.fernunihagen.rtt. ui.internal.view Tabelle A.6: Übersicht der RTT Paketstruktur Teil 3 72

73 B Schnellstartanleitung B.1 Installation und Deinstallation B.1.1 Auslieferung Zu der Auslieferung des Refactoring Tool Testers gehören die nachfolgenden Feature, die über die RTT Update-Site installiert werden können: RTT Core beinhaltet die Kernbestandteile des RTT-Frameworks. RTT SVN Connector stellt einen Konnektor zur Anbindung von SVN Repositories zur Verfügung. RTT UI beinhaltet alle Komponenten der Benutzerschnittstelle. RTT JQuery Test Adapter enthält einen deklarativen Abfragewerkzeug-Testadapter, der JQuery verwendet (JQuery-Testadapter). B.1.2 Voraussetzungen Die Installation des RTT setzt folgende Umgebung voraus: Eclipse Java Development Tools 3.5 [4] Subversive SVN Team Provider (Incubation) 0.7 [4] Subversive SVN Connectors 2.2 [19] SVNKit 1.3 Implementation [19] JQuery Backend Plugin [32] TortoiseSVN for Windows [30] (Optional) Nach Installation von Eclipse können die SVN Feature über die entsprechenden Update- Sites installiert werden. Um SVN nutzen zu können, muss allerdings ein SVN-Server installiert werden. Für ein Windows basiertes Zielsystem wird, zur einfachen Erzeugung und Verwaltung von SVN Repositories, der TortoiseSVN Client vorgeschlagen, mit dessen Installation auch ein SVN-Server bereitsteht. Unter der Ubuntu Linux Distribution steht SVN über das Software Repository bereit [31]. Zur Installation des JQuery Plugin steht keine Update-Site zur Verfügung, bitte die Installationshinweise des Herstellers beachten. 73

74 B Schnellstartanleitung B.1.3 Installation Der RTT kann, in der o.g. Umgebung, einfach über den Eclipse Update-Manager installiert werden. Hierzu ist es notwendig dem Update-Manager den Ort der lokalen RTT Update- Site mitzuteilen. Zur Installation des RTT: 1. Eclipse starten und das Menü 'Help > Install New Software...' auswählen. Abbildung B.1: Software Updates 74

75 B Schnellstartanleitung 2. Über 'Add > Local' das Hauptverzeichnis der RTT-Update-Site eintragen und die gewünschten RTT-Feature auswählen. Abbildung B.2: Installation und Feature-Auswahl 3. Mit 'Next' die Auswahl bestätigen und nach Annahme der Lizenzbedingungen die Installation einleiten 'Finish'. 4. Nach erfolgreicher Installation Neustart bestätigen 'Yes'. Abbildung B.3: Installation abschlieÿen 75

76 B Schnellstartanleitung B.1.4 Deinstallation Zur Deinstallation der RTT Feature: 1. Eclipse starten und das Menü 'Help > About Eclipse...' auswählen, um zu den Installationsdetails zu gelangen. Abbildung B.4: About Eclipse und Installationsdetails 2. Aktion 'Installation Details' bestätigen und in der Liste 'Installed Software' die bereits installierten RTT-Feature selektieren. Eine Mehrfachauswahl ist über STRG möglich. Abbildung B.5: Installationsdetails 3. Über 'Uninstall' die Auswahl bestätigen. 76

77 B Schnellstartanleitung 4. Die Deinstallation über die Aktion 'Finish' abschlieÿen. Abbildung B.6: Deinstallation 5. Nach erfolgreicher Deinstallation Neustart bestätigen 'Yes'. Abbildung B.7: Deinstallation abschlieÿen B.2 Erzeugen von Testprojekten Nachfolgend wird die Vorgehensweise zum Erzeugen eines Testprojektes für den JQuery Testadapter, am Beispiel eines Testfalls für das Rename-Refaktorisierungswerkzeug, vorgestellt. Die vollständige Implementierung des Beispiels ist dem beigefügten Testprojekt- Archiv zu entnehmen. Die Vorgehensweise zum Import eines existierenden Projektes aus einem Projekt-Archiv ist im Abschnitt B.3.1 in den Schritte 1-3 beschrieben. 77

78 B Schnellstartanleitung Zur Erstellung eines Testprojektes: 1. Eclipse starten und das Menü 'File > New > Project...' auswählen, um zum Dialog 'New Project' zu gelangen. Abbildung B.8: Erzeugen eines Projektes 2. Den Eintrag 'Plug-in Project' auswählen und mit 'Next' bestätigen. Abbildung B.9: Erzeugen eines Plugin-Projektes 78

79 B Schnellstartanleitung 3. Im Dialog 'New Plug-in Project' den geeigneten Projektnamen vorgeben und mit 'Next' bestätigen. Abbildung B.10: Einstellungen eines Plugin-Projektes 4. Die Optionen 'Generate an activator...' und 'This plug-in will make contributions to the UI' können deaktiviert werden. Anschlieÿend das Erzeugen des Projektes mit 'Finish' einleiten. Abbildung B.11: Inhalt eines Plugin-Projektes 79

80 B Schnellstartanleitung 5. Im Manifest Editor das Tab 'Dependencies' aktivieren und über die Aktion 'Add' die Abhängigkeit auf das RTT Core Plug-in (de.fernunihagen.rtt) einfügen. Abbildung B.12: Abhängigkeit auf RTT Core Plugin 6. Über das Menü 'File > New > Class' einen Test Klasse für die zu implementierenden Testfälle erzeugen. Abbildung B.13: Test-Klasse erzeugen 80

81 B Schnellstartanleitung 7. Im Dialog 'New Java Class' einen geeigneten Namen für die Test-Klasse vorgeben und mit 'Finish' die Erzeugung einleiten. Abbildung B.14: Informationen der Test-Klasse festlegen 8. In den Editor wechseln, um mit der Codierung der Testfälle zu beginnen. B.3 Erzeugen von Kongurationen B.3.1 Bereitstellung von Probanden-Projekten Nach der erfolgreichen Installation des RTT und der Einrichtung eines SVN Repositories, sind vor einem Testlauf noch Probanden bereitzustellen. Als Proband kommt jedes beliebige Eclipse Java-Projekt für den RTT in Frage. Eclipse Java-Projekte, die bereits in einem SVN Repository verwaltet sind, benötigen keine Vorbereitung um als Probanden zu fungieren für diese Projekte können die nachfolgenden Schritte übersprungen werden. Im nachfolgenden Beispiel dient ein, speziell für das Testprojekt des Rename-Refaktorisierungswerkzeugs, vorbereitetes Java-Projekt als Testeingabe. Die Schritte 1-3 beschreiben den Vorgang des Imports dieses Java-Projektes aus dem beigefügten Projekt-Archiv. Falls das Projekt bereits im Workspace vorliegt können diese Schritte übersprungen werden. 81

82 B Schnellstartanleitung Zur Vorbereitung eines neuen Probanden: 1. Eclipse starten und 'File > Import' auswählen. Abbildung B.15: Import Aktion 2. Die Import Aktion in der Kategorie 'General > Existing Projekt into Workspace' auswählen und mit 'Next' bestätigen. Abbildung B.16: Import eines bestehenden Projektes 82

83 B Schnellstartanleitung 3. Im Feld 'Select archive le' den Pfad zum Eclipse Java-Projekt-Archiv angeben und nach Selektion der zu importierenden Projekte im Archiv, den Import über 'Finish' anstoÿen. Abbildung B.17: Import aus einem Projekt-Archiv 83

84 B Schnellstartanleitung 4. Das importierte Projekt im Workspace auswählen und über das Kontextmenü 'Team > Share Project...' die Verknüpfung zu einem Team Repository aufbauen. Abbildung B.18: Projekt mit Repository verknüpfen 5. Im Dialog 'Share Project' den SVN Connector auswählen und die Selektion mit 'Next' bestätigen. Abbildung B.19: SVN Connector Auswahl 84

85 B Schnellstartanleitung 6. Im Dialog 'Share Project Wizard' die URL des SVN Repository ausweisen und mit 'Next' bestätigen. Abbildung B.20: Repository Informationen festlegen 7. Die Aktion 'Share Project' mit 'Finish' abschlieÿen. 8. Die Übergabe des Projektes im Dialog 'Commit' bestätigen. Abbildung B.21: Initialer Commit 85

86 B Schnellstartanleitung 9. Abschlieÿend steht das Projekt zur Selektion innerhalb einer RTT-Testkonguration zur Verfügung womit die Vorbereitungen erfolgreich abgeschlossen sind. 10. Die Aktionen 1-9 zur Vorbereitung weitere Probanden wiederholen. B.3.2 Launch-Konguration Über die Launch-Konguration des RTT wird die notwendige Testkonguration für einen Testlauf erzeugt. Notwendige Bestandteile für eine Testkonguration sind: das Testprojekt für das zu testende Refaktorisierungswerkzeug und die vorbereiteten Probanden. Zum erzeugen einer neuen Lauch-Konguration: 1. Eclipse starten und in das Workspace wechseln, in dem die vorbereiteten Projekte vorliegen. 2. Das Testprojekt selektieren und über das Kontextmenü 'Run as > Run Congurations...' auswählen. Abbildung B.22: Launch-Konguration önen 86

87 B Schnellstartanleitung 3. Aus der Liste der verfügbaren Kongurationstypen 'RTT Java' auswählen und über das Kontextmenü 'RTT Java > New' eine neue Konguration erzeugen. Abbildung B.23: Testkonguration erzeugen 4. Im Tab 'Test' der Konguration das Test-Projekt auswählen. Abbildung B.24: Auswahl des Testprojektes 5. Im Baum der Testprojekt-Konguration erscheinen die verfügbaren Test-Klassen, in 87

88 B Schnellstartanleitung denen Testfälle enthalten sind. Durch Selektion bzw. Deselektion von Test-Klassen können enthaltene Testfällen ausgeschlossen werden. 6. Zum Ausschluss von Ressourcen aus Probanden (Test-Subject), für den jeweiligen Test-Aktor, in der Spalte der Testadapter oder Orakel, entsprechende Ressourcen selektieren. In der Standardauswahl sind alle Ressourcen enthalten. Die aktuelle Auswahl kann durch speichern 'Test-Subject Congurations > Toolbar' als Standardkonguration im Probanden-Projekt hinterlegt werden, so dass für neue Launch- Kongurationen mit demselben Probanden-Projekt die Einstellungen übernommen werden. Zu Beachten ist, dass im Baum der Probanden-Konguration jeweils nur die, für den Test-Aktor, anwendbare Ressourcen auswählbar sind. Abbildung B.25: Aktor-Konguration eines Probanden 88

89 B Schnellstartanleitung 7. Über das Kontextmenü im Baum der Probanden-Konguration oder der Toolbar können Projekte hinzugefügt oder entfernt werden. In der Projekt-Auswahl erscheinen im Workspace enthaltene Java-Projekte, die nicht bereits in der Konguration enthalten sind und erfolgreich vorbereite wurden. 1 Abbildung B.26: Hinzufügen von Probanden zur Konguration 8. Die Standard Launch-Kongurationseinstellungen wie z.b. Main, Arguments oder Common können über die gleichnamigen Tabs verändert werden, so z.b. die Auswahl des Workspace oder der Speicherort der RTT Launch-Konguration. 9. Nach erfolgreicher Konguration kann über 'Run' ein Testlauf gestartet werden, der in einer neuen Eclipse Instanz ausgeführt wird. Anmerkung Nach Erzeugung einer Launch-Konguration dürfen die Probanden aus dem Workspace entfernt werden. Vor einer erneuten Veränderung der Launch-Konguration werden diese dann ggf. automatisch abgerufen. B.4 Debuggen Um ein Testfall zu Debuggen muss eine Launch-Konguration im Debug-Mode gestartet werden. Die Schritte zur Erzeugung der Launch-Konguration sind im Abschnitt B In der vorliegenden Version sind Plugin-Projekte ausgeschlossen 89