ABBILDUNGSVERZEICHNIS...I TABELLENVERZEICHNIS... II LISTINGVERZEICHNIS... III 1 EINLEITUNG...

Transkript

1 Inhaltsverzeichnis ABBILDUNGSVERZEICHNIS...I TABELLENVERZEICHNIS...II LISTINGVERZEICHNIS... III 1 EINLEITUNG MOTIVATION ZIEL DER ARBEIT INHALT UND AUFBAU GRUNDLEGENDE KONZEPTE TRACING CODE-INSTRUMENTIERUNG MODIFIZIERUNG DER JAVA LAUFZEIT-BIBLIOTHEK JAVA PLATFORM DEBUGGER ARCHITECTURE ASPEKTORIENTIERTE PROGRAMMIERUNG Motivation AspectJ Tracing mit AOP ZUSAMMENFASSUNG ANFORDERUNGSANALYSE ANWENDUNGSFÄLLE SZENARIO: LAUFZEITVERHALTEN AUFZEICHNEN SZENARIO: TRACING MIT CODE-INSTRUMENTIERUNG SZENARIO: TRACING MIT AOP SZENARIO: TRACING MIT JPDA SZENARIO: TRACINGDATEN AUSWERTEN FUNKTIONALE ANFORDERUNG NICHT-FUNKTIONALE ANFORDERUNGEN ENTWURF UND IMPLEMENTIERUNG SYSTEM-ARCHITEKTUR SOFTWAREARCHITEKTUR DESIGN & IMPLEMENTIERUNG STAND DER REALISIERUNG UND FALLBEISPIEL REALISIERUNG FALLBEISPIEL ABSCHLUSS ZUSAMMENFASSUNG AUSBLICK LITERATURVERZEICHNIS GLOSSAR ANHANG A FALLBEISPIEL

2 ANHANG B FALLBEISPIEL ANHANG C INSTALLATIONSHINWEISE ANHANG D BENUTZUNGSHINWEISE ANHANG E DTD FÜR DIE XML-DATEI... 89

3 i Abbildungsverzeichnis Abbildung 2.1 JPDA-Architektur...9 Abbildung 2.2 Implementierung von Logging mit OOP Abbildung 2.3 Modularisierung mit AOP...12 Abbildung 2.4 Aspektweber...13 Abbildung 2.5 Realisierung der Tracing-Funktionalität in einer Java-Anwendung...15 Abbildung 3.1 Anwendungsfalldiagramm: Java Usability Tracing System...19 Abbildung 3.2 Szenario: Tracing mit Code-Instrumentierung...21 Abbildung 3.3 Szenario: Tracing mit AOP...23 Abbildung 3.4 Szenario: Tracing mit JPDA...24 Abbildung 3.5 Szenario: Tracingdaten auswerten...25 Abbildung 4.1 Systemarchitektur Tracing mit AOP...31 Abbildung 4.2 Schichtenmodell des Prototyps...32 Abbildung 4.3 Schnittstelle zum Zugriff auf die Anwendungsschicht...34 Abbildung 4.4 Implementierung der verschiedenen Tracing-Ansätze...35 Abbildung 4.5 Nachbildung der statischen Struktur...37 Abbildung 4.6 Einheitliche Schnittstelle für die Logging-Funktion...40 Abbildung 5.1 Record-Mode: Eingabe der erforderlichen Daten...43 Abbildung 5.2 Eingabe der Klassenpfade...44 Abbildung 5.3 Filtereinstellung...45 Abbildung 5.4 Kompilieren...47 Abbildung 5.5 Überwachung der zu analysierenden Anwendung...47 Abbildung 5.6 Eintritt einer Ausnahmebehandlung...48 Abbildung 5.7 Play-Mode...49 Abbildung 6.1 Eingabe der erforderlichen Daten...84

4 ii Tabellenverzeichnis Tabelle 2-1 Tracing-Ansätze...6 Tabelle 2-2 Vergleich der vier Tracing-Ansätzen...17 Tabelle 3-1 Funktionale Anforderungen an den Prototyp...28 Tabelle 3-2 Nicht-funktionale Anforderungen an den Prototyp...29 Tabelle 4-1 Beschreibung der Zuständigkeiten der Schichten...33 Tabelle 4-2 Elemente der statischen Struktur...36 Tabelle 4-3 Übermittelte Informationen mit dem Ereignis Methodeneintritt & -austritt...39 Tabelle 4-4 Verfügbare Ereignisse für das Tracing...39 Tabelle 5-1 Stand der Realisierung: funktionale Anforderungen...42 Tabelle 5-2 Hinweise beim Kompilierungsvorgang...46 Tabelle 5-3 Symbol der Ereignisse...46

5 iii Listingverzeichnis Listing 2-1 HelloWorld Beispiel mit Logging als Crosscuting concerns...12 Listing 2-2 Implementierung des Aspektcodes für das Beispiel in Listing Listing 2-3 Implementierung des Codes in Listing 2.1 ohne Crosscuting concerns...14 Listing 4-1 Template für den Traceaspekt-Code...38

6 Kapitel 1. Einleitung 1 Kapitel 1 Einleitung 1.1 Motivation Neben der Verwirklichung innerer Softwarequalität ist die optimale Erfüllung äußerer Qualitätsmerkmale eine zweite Herausforderung. In diesem Zusammenhang ist Benutzbarkeit von Software anzuführen. Benutzbarkeit bedeutet zum Einen, wie einfach das Programm zu bedienen ist, und zum Anderen, wie schnell seine Funktionalität erfasst und erlernt werden kann. Es existieren in diesem Sinne verschiedene Verfahren, mit denen die Benutzbarkeit von Software beurteilt werden kann. Ein mögliches Verfahren ist die Protokollierung der Interaktionen zwischen einem Benutzer und dem Programm. Es stellt sich aber schnell heraus, dass die Umsetzung dieses Verfahrens besondere Konzepte erfordert, wenn alle Vorgänge möglichst präzise protokolliert werden sollen. An der Hochschule für angewandte Wissenschaften in Hamburg wird dieses Ziel mit der Einrichtung einer Usability-Labor näher verfolgt. In dem Labor werden die Interaktionen des Benutzers mit dem Programm gefilmt und dessen Kommentare aufgezeichnet. Somit kann man die kritischen Stellen bei der Benutzung des Programms leichter analysieren, da die Stellen oft wiederholt werden können. Um die Analyse des aufgenommenen Materials komplementär zu unterstützen, entsteht der Bedarf nach einem geeigneten Werkzeug, das die relevanten internen Vorgänge innerhalb des Programms während des Benutzungstests aufzeichnet und diese mit den kritischen Stellen im Film anhand Zeitmarke synchronisieren kann. Hieraus lassen sich folgende Anforderungen für das Werkzeug ableiten: Die im Programm durch die Benutzer-Interaktionen entstehenden Objekte und deren Dynamik sollen zur Laufzeit verfolgt und aufgezeichnet werden. Dieses Erstellen eines Protokolls des Programmablaufs wird im Verlauf dieser Arbeit als Tracing benannt.

7 Kapitel 1. Einleitung 2 Die aufgezeichneten Informationen sollen anhand einer Zeitmarke referenziert werden können. Zurzeit steht kein Mechanismus im Labor zur Verfügung, um das Programm und das Werkzeug hardwaremäßig zu synchronisieren. Das bedeutet, absolute Synchronisierung ist nicht gewährleistet. Um mit diesem Problem umzugehen, ergeben sich andere Anforderungen an das Werkzeug: Das Werkzeug soll bei bestimmten Ereignissen der Benutzeroberfläche des Programms einen Schnappschuss des Bildschirmfotos (Screenshot) des Programms erfassen. Außerdem sollen die Audio-Kommentare des Benutzers aufgezeichnet werden. Hiermit hat man zumindest durch Vergleich des Videobilds und des Bildschirmfotos bzw. der Audio-Kommentare des Benutzers eine genügende Synchronisierungsmöglichkeit. 1.2 Ziel der Arbeit Diese Arbeit verfolgt das Ziel, ein Konzept zu entwickeln, um Tracing mit Hilfe der Aspektorientierte Programmierung zu realisieren. Die oben genannten Anforderungen an das Werkzeug sollen bei der Konzeption berücksichtigt werden. Auf Basis dieser Anforderungen soll ein Prototyp entwickelt werden, der die Machbarkeit des Konzeptes demonstriert. Folgende Randbedingungen werden im Rahmen dieser Arbeit festgelegt: Der Prototyp wird in der Programmiersprache Java implementiert. Der Prototyp soll als Single-User-System implementiert werden. Die zur Laufzeit zu analysierenden Programme sollen ausschließlich objektorientierte Systeme und Java-Programme sein. 1.3 Inhalt und Aufbau Diese Arbeit ist in folgende Kapitel unterteilt: Im Kapitel 2 werden die einführenden und grundlegenden Konzepte erläutert. Um einen Einblick in den Problembereich zu bekommen, wird zunächst ein Überblick über Tracing gegeben. Es werden die unterschiedlichen Anwendungsgebiete erklärt. Anschließend wird eine Übersicht über Tracing-Ansätze in Java diskutiert. Dabei wird den Einsatz der Code-Instrumentierung, der Java Plattform Debug Architektur, der modifizierten Java-Laufzeit-Bibliothek und der aspektorientierte Programmie-

8 Kapitel 1. Einleitung 3 rung behandelt. Es wird gezeigt, dass mittels aspektorientierter Programmierung einige Nachteile der anderen Ansätze vermieden werden können. Im Kapitel 3 werden die an den Prototyp gestellten Anforderungen beschrieben. Die Anforderungen basieren auf den abgeleiteten Werkzeuganforderungen in Abschnitt 1.1 und gewonnene Erkenntnisse aus dem Kapitel 2.Bei der Anforderungsanalyse dominiert als zentrales Element das Anwendungsfallmodell, das die Benutzer- System- Interaktion aus Benutzersicht modelliert. Anschließend werden die Anforderungen in funktionale und nicht-funktionale Anforderungen aufgeteilt und beschrieben. Im Kapitel 4 werden die Architektur, Entwurf und Implementierung des Prototyps erläutert. Die Struktur des Gesamtsystems wird zunächst dargestellt. Dabei werden die Konzepte für die Realisierung der Tracingfunktionalität mit Hilfe aspektorientierter Programmierung gezeigt. Anschließend werden die wichtigsten Pakete der Anwendung und deren Verantwortlichkeiten beschrieben. In Abschnitt 4.3 wird dann die Klassenstruktur einiger ausgewählter Pakete näher erläutert. Kapitel 5 verschafft einen kurzen Überblick zum Stand der Realisierung. Anhand eines Fallbeispiels wird die Arbeitsweise des Prototyps gezeigt. Abschließend im Kapitel 6 wird die Diplomarbeit zusammengefasst, das Ziel bewertet und ein Ausblick über mögliche Weiterentwicklungen speziell für das Tracing mit Hilfe aspektorientierter Programmierung gegeben.

9 Kapitel 2. Grundlegende Konzepte 4 Kapitel 2 Grundlegende Konzepte Durch die wachsende strukturelle Komplexität von Softwaresystemen und die rapiden Technologiewechsel wird es immer schwieriger, die gewünschte Qualität der Softwaresysteme sicherzustellen. Die Methoden zur Qualitätssicherung lassen sich in statische und dynamische Analysemethoden gliedern. Bei einer statischen Analysemethode wird das Softwaresystem analysiert, ohne das Softwaresystem auszuführen. Eine dynamische Analysemethode verlangt die Ausführung des Softwaresystems mit konkreten Eingaben in der realen Umgebung. Dabei werden relevante Daten aufgezeichnet. Ein Beispiel dafür ist das Tracing. In diesem Kapitel wird ein Überblick über Tracing und dessen Einsatzmöglichkeiten vermittelt. Anschließend werden vier verschiedene Tracingansätze in der Programmiersprache Java diskutiert und gegenübergestellt. 2.1 Tracing Eine Möglichkeit ein Programm zu analysieren besteht darin, Informationen zur Laufzeit zu protokollieren und später auszuwerten. Dieses Mitprotokollieren wird Tracing genannt. Dabei werden wichtige Ereignisse mitprotokolliert. Die Menge der gesammelten Informationen wird im Verlauf dieser Arbeit als Tracerecords, oder auch Tracingdaten bezeichnet. Diese Daten informieren über einen bestimmten Zustand in der Reihe seines Auftretens in der Anwendung. Debugging dient vor allem der Fehlersuche in Programmen. Dazu kann Tracing auch verwendet werden, indem bei der Analyse der Tracingdaten beispielsweise falsche Methodenaufrufe festgestellt werden. Tracing ist jedoch noch wesentlich mächtiger, weil dabei auch Informationen über das dynamische Programmverhalten ermittelt werden, indem alle Methodenaufrufe, Objekterzeugungen, usw. mitprotokolliert werden. Dadurch können kritische Pfade innerhalb einer oder auch mehrerer, Applikationen entdeckt und verbessert werden. Ebenso können dabei unnütze Methodenaufrufe, beispielsweise mehrere Aufrufe der Initialisierungsmethode einer Biblio-

10 Kapitel 2. Grundlegende Konzepte 5 thek, entdeckt und beseitigt werden. Kernigan und Pike haben in Ihrem Buch The Practice Of Programming [KP99, S. 119] die Vorteile des Tracing folgendermaßen dargestellt: As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient. Tracing kann im gesamten Software-Entwicklungszyklus angewendet werden. Abhängig von der jeweiligen Entwicklungsphase: Fehleranalyse. Vor der Fehlerbehebung ist eine Fehleranalyse durchzuführen. Dabei werden Fehler identifiziert und lokalisiert. Zur Fehleranalyse werden neben dem Quellcode und der Systemdokumentation auch die Tracedaten verwendet. Durch die Unterstützung in der Fehleranalyse kann es zu einer schnelleren Fehlerfindung kommen und dadurch zu einer Kostenreduzierung in der Entwicklung und im Support. Architekturanalyse. Die Tracedaten können für eine grafische Darstellung des Programmablaufes verwendet werden. Diese Darstellung (z.b. Sequenz- Diagramm) kann zu Architekturanalysen herangezogen werden. Qualitätssicherung Testen ist für die Software-Qualität unerlässlich. Durch die Verwendung von Tracedaten können Testergebnisse überprüft werden. Zur Überprüfung, ob ein Testlauf erfolgreich war, können die Tracedaten mit denen von früheren Testläufen verglichen werden. Diese Art der Anwendung findet man häufig bei automatisierten Testumgebungen. Wartung. Trotz erfolgreicher Tests sind Probleme im produktiven Einsatz oft unvermeidlich. Die Analyse der Probleme beim Kunden wird durch Tracedaten erleichtert. Evaluationsmethode in der Ergonomie. Die Beurteilung der Benutzbarkeit eines Programms kann durch Tracing unterstützt werden, hierbei interessiert man sich auch für die Verfolgung aller Eingaben am Rechner wie beispielsweise Tastatur und Mausklicks. Es wird zwischen zwei Methoden unterschieden, um die Tracing-Funktionalität in einem bestehenden Programm zu integrieren. Bei invasiven Methoden wird das Pro-

11 Kapitel 2. Grundlegende Konzepte 6 gramm verändert und mit der Tracing-Funktionalität eingefügt. Bei nicht-invasiven Methoden ist es nicht erforderlich, das Programm zu verändern [Renaud 2000]. Im Folgenden werden jeweils zwei Möglichkeiten für invasives und nichtinvasives Tracing in der Programmiersprache Java vorgestellt. Diese Ansätze werden in Tabelle 2-1 dargestellt. Tracing-Ansatz Code-Instrumentierung Modifizierung der Java Laufzeit-Bibliothek Java Platform Debugger Architecture Aspektorientierte Programmierung Methode invasiv nichtinvasiv Tabelle 2-1 Tracing-Ansätze 2.2 Code-Instrumentierung Unter Code-Instrumentierung versteht man das Einfügen von zusätzlichen Code- Anweisungen in den Quellcode. Ein instrumentiertes Programm enthält dann an bestimmten Stellen zusätzlich eingefügte Anweisungen, die zur Aufzeichnung von Informationen während der Programmausführung dienen. Die Instrumentierung kann automatisch durch Werkzeuge, oder manuell erfolgen. Bei der manuellen Instrumentierung werden verschiedene Methoden in der Praxis eingesetzt, angefangen von einfachen,,print -Anweisungen im Quellcode, bis hin zu einer vollständigen Einbindung in ein Logging-Rahmenwerk. Die Code-Instrumentierung hat folgende Vorteile: Die Instrumentierung in den Quellcode kann nachvollzogen werden. Ein Software-Entwickler kann genau entscheiden, welche Teile seines Programms instrumentiert werden sollen, und welche nicht. So werden nur die interessanten Methoden instrumentiert. Bei geeigneter Dokumentation kann die Instrumentierung automatisch zur Dokumentation der Implementierung dienen. Der instrumentierte Quellcode kann mit jedem Java-Compiler in Bytecode überführt und ausgeführt werden. Die Ausführung der eingefügten Anweisungen können je nach Betriebmodus deaktiviert werden. Zu den Nachteilen zählen: Das Programm wird durch Einfügen der Anweisungen verändert. Bei Programmänderungen muss das Programm je nach Anzahl der Instrumentierten Anweisungen in erheblichem Maße verändert werden.

12 Kapitel 2. Grundlegende Konzepte 7 Häufig werden externe Programmbibliotheken, für welche kein Quellcode zur Verfügung steht, eingesetzt. Bei fehlendem Quellcode kann mit der Instrumentierung keine Erweiterung um die Tracing-Funktionalität durchgeführt werden. Es ist schwierig, in Bezug auf die Informationen und den Zeitpunkt zu entscheiden, welche Stellen interessant und welche eher uninteressant sind. Es existiert kein allgemeiner Standard für den Inhalt der Tracingdaten. Im produktiven System müssen die Traceanweisungen entfernt werden oder unwirksam gemacht werden, z.b. aus Performance-Gründen. 2.3 Modifizierung der Java Laufzeit-Bibliothek Eine ähnliche Methode der manuellen Instrumentierung besteht darin, nicht das Programm an sich zu instrumentieren, sondern die benutzten Bibliotheken. Dies kann in Java beispielsweise erfolgen, in dem man die Java Laufzeit-Bibliothek rt.jar instrumentiert. Im Zusammenhang mit der Beurteilung der Benutzbarkeit, kann hier die in der Laufzeit-Bibliothek enthaltene Java-Swing-Bibliothek mit zusätzlichen Anweisungen für die Verfolgung der Mausklicks oder Tastatur-Eingaben eingefügt werden. Dieser Ansatz hat folgende Vorteile: Da nur die Bibliotheken verändert werden, bleibt der Quellcode des Programms unverändert. So kann Tracing einfach und ohne Aufwand einem bestehenden Quellcode hinzugefügt werden. Die einmal instrumentierten Bibliotheken können mit verschiedenen Programmen genutzt werden. Ferner können solche Bibliotheken in verschiedenen Versionen (unter anderem mit und ohne Tracing) auf einem System vorhanden sein. So kann Tracing einfach durch Nutzung der passenden Bibliothek erreicht werden. Die Nachteile sind: Um die Bibliothek angemessen zu instrumentieren, werden tiefe Kenntnisse der Struktur und der Arbeitsweise der Bibliothek erfordert. Es ist nicht immer mit vertretbarem Aufwand möglich, Bibliotheken manuell zu instrumentieren. Dann sollte die Instrumentierung automatisiert werden. Bei Freigabe einer neuen offiziellen Version der Bibliothek durch den Hersteller muss die Konsistenz mit der veränderten Version verglichen werden. Mit diesem Ansatz können nur Bibliotheksaufrufe verfolgt werden, nicht aber Vorgänge innerhalb des Codes der Anwendung. Es existiert kein allgemeiner Standard für den Inhalt der Tracingdaten.

13 Kapitel 2. Grundlegende Konzepte Java Platform Debugger Architecture Die Java Platform Debugger Architecture (JPDA) ist seit dem SDK 1.3 Bestandteil der Java 2 Platform. JPDA bietet komfortable Schnittstellen für die Überwachung von laufenden Java-Programmen [URL JPDA] [Gae03]. In der Praxis wird JPDA meistens für das Debugging verwendet. Die meistens Debugger innerhalb kommerzieller Java-Entwicklungsumgebung wie beispielsweise JBuilder basieren auf der JPDA [URL JBuilder]. Mit JPDA können auch Tracing- und Monitoring-Werkzeuge implementiert werden. Die JPDA besteht aus zwei Schnittstellen (JVMDI und JDI), einem Protokoll (JDWP) sowie zwei Software-Komponenten, die diese Elemente miteinander verbinden (Front-End und Back-End). (siehe Abbildung 2.1): Das Java Virtual Machine Debug Interface (JVMDI) beschreibt die Debugging-Funktionalität einer Java Virtual Maschine (JVM). Diese Schnittstelle beschreibt die Funktion für das Beobachten eines laufenden Programms, das Anhalten und Fortsetzen eines Programms und den Zugriff auf den Zustand eines angehaltenen Programms. Die JVMDI-Referenzimplementierung von Sun Microsystems im SDK 1.3 und 1.4 wird als nativer Bestandteil (C Interface) der JVM implementiert. Auf diesem Interface basiert das Back-End, welches die nativen Funktionsaufrufe für ein plattformunabhängiges Protokoll (JDWP) aufbereitet. Das Java Debug Wire Protocol (JWDP) ist ein Protokoll, um das JVMDI von einem anderen Rechner oder Prozess zu benutzen. Das Protokoll wird von einem Backend auf der JVM des überwachten Programms implementiert. Das Backend leitet Anfragen an das JVMDI weiter und sendet Antworten des JVMDI zurück. Das Java Debug Interface (JDI) ist ein Java-API, um über das JDWP mit dem JVMDI zu kommunizieren. Daher bieten JDI und JVMDI im Wesentlichen die gleiche Funktionalität an. Diese API ( Application Programming Interface ) ermöglicht den komfortablen Zugriff auf das überwachte Programm von einer Java Applikation. Die Implementierung des JDI wird als Frontend bezeichnet. Das überwachende Programm, welches das JDI benützt, und das Frontend laufen auf einer anderen JVM als das überwachte Programm. Das JDWP kann über Shared Memory oder über eine TCP-Verbindung genutzt werden. Diese Auswahl erfolgt über das JDI. Die Überwachung eines Programms läuft wie folgt ab. Entweder verbindet sich das überwachende Programm mit einem bereits laufenden Programm oder das überwachende Programm startet das zu überwachende Programm selber. Zur Beobachtung des laufenden Programms registriert sich das überwachende Programm für Ereignisse, die im JVMDI bzw. JDI vordefiniert sind. Zur Behandlung der Ereignisse stellt

14 Kapitel 2. Grundlegende Konzepte 9 das überwachende Programm Callback-Methoden bereit. Beim Auftreten der Ereignisse werden ereignisspezifische Informationen an diese Methoden übergeben. Das Überwachende Programm Das Überwachte Programm JDI Backend Frontend JVM1 JVMDI JVM2 Abbildung 2.1 JPDA-Architektur Beim Registrieren legt das überwachende Programm außerdem fest, wie das überwachte Programm bei Auftreten der Ereignisse gesteuert wird. Entweder läuft das überwachte Programm weiter oder es wird angehalten (Suspend-Modus). Dieser Ansatz hat folgende Vorteile: Der Quellcode des Programms bleibt unverändert. Demzufolge kann der Quellcode in der Binärform vorliegen. Die JPDA bietet einen Standard für die Verfolgung des Programmablaufs. Die Traceinhalte werden in den von JPDA zur Verfügunggestellten Schnittstellen spezifiziert. JVMDI und JDI bieten die Möglichkeit, Ereignisse beliebiger Pakete und Klassen herauszufiltern. Damit kann man genau auswählen, welcher Teil des Programms überwacht werden soll. Die Nachteile sind: Performanzprobleme. Der gesamte Programmzustand kann nur im Suspend- Modus untersucht werden, das bedeutet bei jedem Methodeneintritt und - austritt muss das Programm kurzzeitig angehalten werden. Die Verwendung des Suspend-Modus verlangsamt das überwachte Programm zusätzlich. Der Einsatz von Filtern verkürzt einerseits die Laufzeit, indem sie die Anzahl der zu behandelnden Ereignisse reduzieren. Andererseits kann die Ausführung von Filtern zu Laufzeit-Overhead führen. Der Laufzeit-Overhead durch die JPDA ist größtenteils erheblich und kann insbesondere bei Tracing von lange laufenden Programmen Probleme bereiten. Probleme können auch entstehen,

15 Kapitel 2. Grundlegende Konzepte 10 wenn das überwachte Programm mit anderen Programmen interagiert, die die Verlangsamung nicht akzeptieren [Gae03],[YRN02]. Die Implementierung des JPDA in Sun s SDK erlaubt keinen direkten Zugriff auf den Rückgabewert einer Methode. Kompilierung mit Debug-Option: Um die volle Funktionalität des JDI nutzen zu können, muss das untersuchte Programm Debug-Informationen enthalten. Das Programm muss mit der Debug-Option (Aufruf des Sun Java Compilers mit javac -g) kompiliert sein. Andernfalls kann nicht auf Variablen und Methodenparameter zugegriffen werden. Diese Einschränkung betrifft nicht die gesamte Java Platform Debugger Architecture (JPDA), sondern nur das Java Debug Interface (JDI). Das JVMDI ermöglicht den Zugriff auf Variablen, auch wenn der entsprechende Code keine Debug-Informationen enthält. 2.5 Aspektorientierte Programmierung Motivation Die Entwicklung komplexer Softwaresysteme ist nur durch Modularisierung und Trennung der Verantwortlichkeiten innerhalb der Module beherrschbar. Objektorientierte Programmierung erlaubt demzufolge die Modularisierung in Klassen. Dennoch bleiben Fälle offen, in denen diese Methode keine Modularisierungsmöglichkeit anbietet. Diese Probleme treten auf, wenn man es mit den so genannten Crosscuting concerns zu tun hat [Kic97],[AJPG03],[Lad03]. Sie werden auch oft als modulübergreifende Anliegen bezeichnet[lau03]. Konto Kunde Angestellter Relevante Codeabschnitte zum Aufrufen der Logging- Dienste Logging Kopplung Abbildung 2.2 Implementierung von Logging mit OOP.

16 Kapitel 2. Grundlegende Konzepte 11 In Abbildung 2.2 ist eine solche Situation für den Anwendungsbereich Bankgeschäfte beispielhaft dargestellt. Mit Objektorientierter Programmierung lassen sich beispielsweise die Objekte wie Konto, Kunde und Angestellter in Klassen kapseln. Solche funktionalen Anforderungen werden als Common concerns bezeichnet [AJPG03], da die Anforderungen die Kern-Funktionalität für den Anwendungsbereich darstellen. Es gibt aber auch andere nicht funktionale, mehr technische Anforderungen. Ein Beispiel dafür ist Logging. Solche Anforderungen werden Crosscutting concerns genannt, weil sie nicht zu den eigentlichen Anforderungen des Anwendungsbereichs gehören, sondern durch diese durchschneiden. Um die Logging- Dienste zu benutzen, müssen in der Klasse Konto, Kunde und Angestellter relevante Codeabschnitte zum Aufrufen der Dienste integriert werden. Dieser Code wird mit Grau-Farbe im Bild dargestellt. Mit Objektorientierter Programmierung ist es nicht möglich, die Crosscutting concerns, die sich durch das gesamte System verstreut vorliegen, getrennt von den funktionalen Anforderungen zu implementieren und in Modulen zu kapseln. Dies führt zu redundantem Code und senkt die Softwarequalität erheblich. Beispielsweise leidet die Wartbarkeit. Müssen Änderungen an dem Code vorgenommen werden, so ziehen sie sich oft durch das gesamte System und müssen mehrfach vorgenommen werden. Es gilt alle entsprechenden Code-Stellen zu finden und zu ändern. Außerdem muss versucht werden sicher zu stellen, dass auch wirklich alle nötigen Änderungen durchgeführt wurden. Dafür bietet die Objektorientierte Programmierung aber keine Verfahren bzw. Methoden an. Implementiert man die Crosscuting concerns dennoch in Klassen, so erfüllen diese zwar nach funktionalen Gesichtspunkten die Forderungen nach loser Kopplung und starkem inneren Zusammenhalt. Aber für die Gesamtheit der Systemanforderungen entsteht folgende Problematik: Auf der einen Seite sind in einer Klasse mehrere Aspekte zu berücksichtigen (die eigentlichen funktionalen und die zusätzlichen technischen), auf der anderen Seite ist ein einzelner Aspekt (Logging) über mehrere Klassen hinweg zerstreut. Dies führt zu den bekannten Problemen fehlender Modularisierung. Eine Lösung bietet hierbei die Aspektorientierte Programmierung (AOP). Dies wird durch Trennung der funktionalen Anforderungen und Crosscutting concerns auf Implementierungsebene ermöglicht. D.h. man versucht die Crosscutting concerns zu erkennen und auszulagern. AOP liefert dafür den benötigten Ansatz zum Erkennen und Abtrennen von den Crosscutting concerns.

17 Kapitel 2. Grundlegende Konzepte 12 OOP Ein Modul (z.b. eine Klasse) AOP Ein Modul (z.b. eine Klasse) Aspekt Funktionaler Code Aspekt- Code Crosscutting concerns Common concerns Abbildung 2.3 Modularisierung mit AOP Das Modul, in dem logisch Crosscutting-concern zusammengepackt sind, wird Aspekt genannt (siehe Abbildung 2.3). Ein Aspekt kapselt Crosscutting concerns ausserhalb eines herkömmlichen Software-Moduls und ist vergleichbar mit einer Java-Klasse. Ein einfaches Beispiel für eine Klasse mit Crosscutting concerns wird in Listing 2-1 gezeigt. In der Methode helloworld wird vor und nach der eigentlichen Ausführung des funktionalen Codes ( hello, world ausdrücken) eine einfache Loggingfunktion ausgeführt. Dieses Logging stellt eine Crosscutting concern dar. public class HelloWorld { public static void helloworld() { //logging System.out.println("Vor der Ausführung von helloworld"); System.out.println("hello, world"); Common concerns //logging System.out.println("Nach der Ausführung von helloworld"); Crosscutting concerns Listing 2-1 HelloWorld Beispiel mit Logging als Crosscuting concerns Die Zusammenführung dieser Crosscutting concerns in einem Aspektcode kann auf vielerlei Weisen geschehen. Eine Möglichkeit wird mit AspectJ in folgenden Kapitel gezeigt.

18 Kapitel 2. Grundlegende Konzepte AspectJ Wie jede Programmiertechnik, erfordert aspektorientierte Programmierung eine Programmiersprache und Werkzeuge für ihre Implementierung, nämlich: die Sprache, in der die Aspekte und ihre Schnittpunkte zur funktionalen Anforderungen spezifiziert werden, und den Aspekt-Weber, der die funktionalen Codes und Aspekt-Codes zu einer Anwendung verbindet. AspectJ ist eine Erweiterung der Programmiersprache Java und implementiert den AOP Ansatz durch neue Konzepte und Sprachkonstrukte. Bei der Ausführung der Anwendung müssen vorher die funktionalen Codes und die Aspect-Codes zusammengebracht werden (siehe Abbildung 2.4). Diese Aufgabe übernimmt der Aspektweber. Der AspectJ-Compiler ist ein Aspektweber für AspectJ. Vom Compiler erzeugte class-dateien sind kompatibel zu Standard-Java-Class-Dateien und sind damit lauffähig auf jeder beliebigen Java Virtuellen Maschine. AOP Klassen Aspekte Funktionale Codes Aspekt- Codes Aspekt- Weber Anwendung (class-datei) AspectJ-Sprache AspectJ-Compiler Abbildung 2.4 Aspektweber Für die Implementierung des Aspekt-Codes werden einige neue Sprach-Konstrukte vom AspektJ spezifiziert, die in Java selbst nicht zu finden sind. Wenn man einen Aspekt-Code mit einem funktionalen Code zusammenführen (weben) will, muss in irgendeiner Weise beschrieben werden, an welchen Stellen der Aspekt-Code zur Geltung kommen soll. Zu diesem Zweck gibt es sogenannte Pointcuts, die einen oder auch mehrere Join Points in einem Programm identifizieren. Joint Points sind die Stellen im funktionalen Code, an denen der Aspekt-Code mit dem funktionalen Code verwebt wird. Der Pointcut execution(public static void Hello- World.helloWorld())im Aspekt LoggingHelloWorldAspect in Listing 2-2 identifiziert beispielsweise die Ausführung der Methode public static void helloworld einer Instanz der Klasse HelloWorld in Listing 2-1. Eine komplette Übersicht aller verfügbaren Pointcuts und ihre Beschreibung findet man in [AJPG2003]. Es ist auch möglich, Pointcuts mit Bezeichnern (im Codebeispiel:

19 Kapitel 2. Grundlegende Konzepte 14 logginghelloworld()) zu versehen, sie also wie Variablen zu deklarieren und später im Code zu verwenden. public aspect LoggingHelloWorldAspect { Pointcut-Bezeichnern //Pointcut-Definitionen pointcut logginghelloworld(): execution(public static void HelloWorld.helloWorld()); Pointcut //Advice-Definitionen before() : logginghelloworld() { System.out.println("Vor der Ausführung von HelloWorld"); after() : logginghelloworld() { System.out.println("Nach der Ausführung von HelloWorld"); Listing 2-2 Implementierung des Aspektcodes für das Beispiel in Listing 2-1. Ein Advice implementiert die an den durch Pointcuts identifizierten Join points durchzuführende Crosscutting-Logik. Dabei wird spezifiziert, ob die Durchführung vor (before) oder nach (after) dem jeweiligen Join Point erfolgt, oder ob er komplett unter der Kontrolle des Advices steht (around), das bedeutet die Ausführung des Join Points kann durch einen around Advice unterbunden werden. Im Beispiel in Listing 2-2 werden zwei Advices definiert: Der erste Advice wird vor der Ausführung der mit logginghelloworld definierten Pointcut ausgeführt. Der zweite Advice wird dann nach der Ausführung des definierten Pointcuts ausgeführt. Somit kann man mit dem Aspekt-Code in Listing 2-2 die Logging-Funktion (Crosscuting concerns) im Codebeispiel in Listing 2-1 realisieren, ohne diese im funktionalen Code zu implementieren (siehe Listing 2-3). Fdfdfd Um Tracing mit Hilfe der Aspektorientierte Programmierung zu realisieren, wird das Tracing als Crosscutting concern betrachtet. Demzufolge erfolgt die Implementiepublic class HelloWorld { public static void helloworld() { System.out.println("hello, world"); Listing 2-3 Implementierung des Codes in Listing 2.1 ohne Crosscuting concerns Tracing mit AOP

20 Kapitel 2. Grundlegende Konzepte 15 rung als Trace-Aspekt. Um in einer Java-Anwendung die Trace-Funktionalität zu integrieren, werden die beiden Codes mit einem Aspektweber zusammengefügt. Dieser Vorgang wird in Abbildung 2.5 dargestellt. Java- Anwendung + Trace- Aspekt Aspekt- Weber Java-Anwendung + Tracing Funktionalität Abbildung 2.5 Realisierung der Tracing-Funktionalität in einer Java-Anwendung Dieser Ansatz hat folgende Vorteile: Der Quellcode der Anwendung wird nicht verändert und kann in der Binärform vorliegen. Bessere Performanz als JPDA. Der Quellcode der Anwendung und der Aspektcode werden durch einen Compiler einmalig miteinander verwebt. Das heißt die Verknüpfungen sind danach nicht mehr änderbar. Dies hat den Vorteil, dass der Code für seinen Einsatz optimiert werden kann: z.b. dass der Compiler Inlinecode daraus macht. Der zusätzliche Laufzeit-Overhead durch die Verwebung kann im Normalfall vernachlässigt werden [Dav03] [PGG02], [Aspectj_FAQ]. Modularisierte Implementierung der Tracing-Funktionalität. Die Folge ist ein leichtes handhabbares und besser wartbares System. Automatisierung der Instrumentierung auf die Bytecode-Ebene. Dadurch hat dieser Ansatz auch alle Vorteile der Code-Instrumentierung. Die Traceinhalte werden in der AspectJ-API spezifiziert. Die Nachteile sind (bedingt durch die Einschränkungen des jetzigen Aspectj- Compilers Version 1.1.1): Die Binär-Dateien müssen im Form von kompilierter JAR-Datei zur Verfügung gestellt. Vor der Ausführung der Anwendung müssen die Codes der Anwendung und die Aspektcodes verwebt werden. Bei komplexen Anwendungen ist der Kompilierungsvorgang zeitaufwendig. Join Points im Code von nativen Methoden (Java Native Interface) können nicht verwebt werden.

21 Kapitel 2. Grundlegende Konzepte Zusammenfassung Die Ansätze lassen sich für den Tracing-Einsatz nach folgenden relevanten Kriterien unterscheiden: Instrumentierungsaufwand. Das Einfügen von Traceausgaben in den Quellcode kann je nach verwendeter Technik zu einem aufwendigen Prozess werden. Die Praxis hat gezeigt, dass vor allem einfache Lösungen, die diesen Aufwand gering halten, von den Entwicklern akzeptiert werden. Die Verfügbarkeit des Quellcodes. Im Idealfall soll der Quellcode der Anwendung nicht verändert werden, weil er beispielsweise nicht verfügbar ist oder nur in binärer Form vorliegt. Laufzeit-Overhead. Durch die Ausführung zusätzlicher Programmanweisungen des Tracings wird die Laufzeit eines Softwaresystems verlängert. Die Verlängerung der Ausführungszeit wird auch Laufzeit-Overhead genannt. Eine Minimierung des Overhead ist wünschenswert. Traceinhalte. Eine Traceausgabe ist immer eine Momentaufnahme des aktuellen Zustandes. Damit eine Traceausgabe für die weitere Verarbeitung nützlich ist, sollte diese am bestimmten Standard festhalten. Mindestens sollten folgenden Informationen enthalten sein: - Fortlaufende Nummer und Zeitmarke. Dadurch kann die Reihenfolge der Traceausgaben ermittelt werden. - Herkunft. Gibt an, von welchem Prozess / Programmteil / Methoden die Traceausgabe erstellt wurde. - Parameterwert und andere Kontextinformationen. - Beschreibung. Information über den Grund der Traceausgabe. Wartbarkeit. Die Tracingfunktionalität sollte bei Code-Änderungen der Anwendung einfach wartbar sein. Die vier Tracing-Ansätze lassen sich nach den obigen genannten Kriterien vergleichen. In Tabelle 2-2 ist der Vergleich zusammengefasst.

22 Kapitel 2. Grundlegende Konzepte 17 Vergleichskriterien Instrumentierungsaufwand Verfügbarkeit des Quellcodes Laufzeit-Overhead TraceInhalte Wartbarkeit Legende: 1. Code-Instrumentierung 2. Modifizierung der Laufzeit-Bibliothek 3. Java Platform Debugger Architecture 4. Aspektorientierte Programmierung Tabelle 2-2 Vergleich der vier Tracing-Ansätzen Die Tabelle 2-2 zeigt, dass Tracing mit Hilfe aspektorientierter Programmierung eine Lösung für die Probleme der drei anderen Ansätze ist.

23 Kapitel 3. Anforderungsanalyse 18 Kapitel 3 Anforderungsanalyse In diesem Kapitel werden die an den Prototyp gestellten Anforderungen beschrieben. Die Anforderungen basieren auf den abgeleiteten Werkzeuganforderungen in Abschnitt 1.1 auf Seite 1 und den Erkenntnissen aus Kapitel 2. Bei der Anforderungsanalyse dominiert als zentrales Element das Anwendungsfallmodell, das die Benutzer- System- Interaktion aus Benutzersicht modelliert. Anschließend werden die Anforderungen in funktionale und nicht-funktionale Anforderungen aufgeteilt und beschrieben. 3.1 Anwendungsfälle Anwendungsfälle sind ein Hilfsmittel zur Anforderungsanalyse im Rahmen eines objektorientierten Entwicklungsprozesses. Durch einen Anwendungsfall wird eine typische Interaktion eines Benutzers mit einem Computersystem beschrieben. Es wird damit das gewünschte externe Systemverhalten aus Sicht des Benutzers beschrieben. [Kal01] Ein UML-Anwendungsfalldiagramm in Abbildung 3.1 gibt einen Überblick über die identifizierten Anwendungsfälle des Prototyps und zeigt Beziehungen zwischen den Anwendungsfällen und ihren Akteuren. Es werden vier konkrete und fünf abstrakte Anwendungsfälle identifiziert. Ein abstrakter Anwendungsfall ist nicht instanziierbar. Somit können abstrakte Anwendungsfälle niemals allein existieren, sondern werden immer als Teil eines anderen Anwendungsfalles ausgeführt. Der Name der abstrakten Anwendungsfälle wird kursiv geschrieben. Mit der <<include>>- Beziehung wird dargestellt, dass innerhalb eines Anwendungsfalles ein anderer Anwendungsfall vorkommt. [OMG01].

24 Kapitel 3. Anforderungsanalyse 19 Java Usability Tracing System Benutzer Erfassung mit AOP Erfassung mit modifiziertem JDK Java-Anwendung Screenshot erfassen Audio aufzeichnen <<include>> <<include>> Laufzeitverhalten aufzeichnen Tracing mit der Code Instrumentierung Tracing mit AOP Tracing mit JPDA Protokolle auswerten Abbildung 3.1 Anwendungsfalldiagramm: Java Usability Tracing System Durch Szenarios werden die identifizierten Anwendungsfälle weiter spezifiziert. Ein Szenario beschreibt die Interaktionsfolge zwischen dem Benutzer und dem zu entwickelnden Prototyp aus Sicht des Benutzers. Im Folgenden werden anhand von Szenarios auf die wichtigsten Anwendungsfälle eingegangen. Die Szenarios werden als UML-Sequenzdiagramme dargestellt. 3.2 Szenario: Laufzeitverhalten aufzeichnen 1. Der Benutzer wählt einen Tracing-Ansatz, der für das Tracing eingesetzt wird. Folgende drei Ansätze werden als Auswahl zur Verfügung gestellt: Tracing- mit Code-Instrumentierung Tracing mit Hilfe aspektorientierter Programmierung Tracing mit JPDA

25 Kapitel 3. Anforderungsanalyse Der Benutzer gibt Daten an, um die Java-Anwendung zu analysieren und zu starten. Die eingegebenen Daten werden vom Prototyp überprüft. Bei einer fehlerhaften Eingabe wird dem Benutzer eine Fehlermeldung am Bildschirm mitgeteilt. Folgende Angaben sind bei allen Ansätzen erforderlich: - Ein Quellverzeichnis, das die Quellcode oder die binären Programmdateien enthält. - Ein Verzeichnis der Java-Laufzeitumgebung. Der Prototyp erkennt automatisch deren Verzeichnis, wenn diese auf dem Rechner richtig installiert ist. Optional kann der Benutzer folgende Daten angeben: - Ein Verzeichnis der modifizierten Java-Laufzeit-Bibliothek für die Screenshot-Erfassung. - Ein Hilfsklassenpfad, der Bibliotheken enthält, die die Java-Anwendung zur Ausführung benötigt. - Ein zum Starten der Anwendung benötigtes Programmargument. Der Benutzer kann optional den einzusetzenden Ansatz (Modifizierte Java- Laufzeit-Bibliothek oder AOP) zur Erfassung der Screenshots auswählen. Folgende Datenangaben sind für die Speicherung der aufgezeichneten Tracingdaten erforderlich: - Ein Verzeichnis und ein Name der XML-Datei der aufzuzeichnenden Tracingdaten. Als die Standardeinstellung wird ein Standard-Benutzerverzeichnis angegeben - Das Verzeichnis und Name der MP3-Datei der Audiokommentare (optional) - Ein Verzeichnis der Screenshots (optional). Die Aufzeichnung der Audio-Kommentare und der Screenshots kann deaktiviert werden. 3. Bei allen Ansätzen wird das Tracing mit der Start-Taste gestartet. Die Java- Anwendung wird ausgeführt und erscheint an der Oberfläche. Der Benutzer kann jetzt Aktionen auf der Anwendung direkt ausführen. 4. Das Tracing wird beendet, wenn der Benutzer auf die Stopp-Taste drückt. Damit wird auch die Java-Anwendung beendet. 5. Nach einer erfolgten Ausführung der Aktion Nr. 3 und 4 kann der Benutzer die Tracingdaten in einer XML-Datei speichern.

26 Kapitel 3. Anforderungsanalyse Szenario: Tracing mit Code-Instrumentierung Prototyp Benutzer 1: Tracing mit Code-Instrumentierung wählen 1.1: GUI anzeigen 2: Erforderliche Daten eingeben 2.1: Dateneingabe überprüfen 3: Java-Anwendung starten 3.1: Anwendung starten Java-Anwendung 4:*[Aktion!= Ende-Aktion] //Aktion ausführen 5: Tracingdaten an den Prototyp senden 5.1: Tracingdaten anzeigen 6: Java-Anwendung beenden 6.1: Anwendung beenden 7: Tracingdaten speichern Abbildung 3.2 Szenario: Tracing mit Code-Instrumentierung Das Diagramm in Abbildung 3.2 beschreibt die Vorgänge, die beim Tracing mit der Code-Instrumentierung ablaufen. Dieser Anwendungsfall erweitert und erbt das Verhalten des Ober-Anwendungsfalles Laufzeitverhalten aufzeichnen. 1. Der Benutzer wählt den Tracing-Ansatz mit der Code-Instrumentierung aus und gibt alle Datenangaben wie im Ober-Anwendungsfall Laufzeitverhalten aufzeichnen an. Zusätzlich muss eine Klasse (mit main methode), die zum Starten der Java-Anwendung aufgerufen werden soll, angegeben werden. 2. Um die Java-Anwendung zu starten, führt der Benutzer die Aktion Nr. 3 im Ober- Anwendungsfall aus.

27 Kapitel 3. Anforderungsanalyse Bei jeder Ausführung der explizit instrumentierten Anweisungen in der Java- Anwendung werden die internen Ereignisse an den Prototyp weitergeleitet und am Bildschirm präsentiert. 4. Der Benutzer kann die Aktionen Nr. 4 und 5 im Ober-Anwendungsfall ausführen. 3.4 Szenario: Tracing mit AOP 1. Der Benutzer wählt den Tracing-Ansatz mit Hilfe aspektorientierter Programmierung aus. Der Prototyp zeigt dann die entsprechende GUI-Komponente an. Der Benutzer gibt alle erforderliche Datenangabe wie im Ober-Anwendungsfall Laufzeitverhalten aufzeichnen an. Zusätzlich für die Datenangabe ist ein Verzeichnis des Aspectj-Compilers bei diesem Ansatz erforderlich. Als die Standardeinstellung wird der AspectJ-Compiler in der Version 1.1.1, der mit dem Prototyp geliefert wird, verwendet. 2. Der Benutzer kann einen Beobachtungsfilter definieren, indem er die Taste Filter betätigt. Dafür analysiert der Prototyp die statische Struktur der Java- Anwendung und präsentiert sie dem Benutzer am Bildschirm. Mit dem Filter kann der Benutzer gezielt auswählen, welche Teile Pakete, Klassen und Methoden- der Java-Anwendung analysiert werden sollen. Hier kann der Benutzer die Startklasse ( Klasse mit main Methode) angeben, die zum Starten der Java- Anwendung aufgerufen werden soll. 3. Um die Java-Anwendung zu starten, führt der Benutzer die Aktion Nr. 3 im Ober- Anwendungsfall aus. Der Prototyp generiert anschließend abhängig von der Filtereinstellung in Aktion Nr. 2 einen Aspektcode. Der Aspektcode wird dann mit dem Code der Java-Anwendung verwebt. Dabei werden nur relevante Teile der Anwendung abhängig von der Filtereinstellung mit dem Aspektcode verwebt. Anschließend startet der Prototyp die Java-Anwendung in einem neuen Prozess. 4. Die Java-Anwendung leitet dann die Tracingdaten an den Prototyp weiter. Der Prototyp präsentiert sie dem Benutzer am Bildschirm. 5. Der Benutzer kann die Aktionen Nr.4 & 5 im Ober-Anwendungsfall ausführen. Die beschriebenen Szenarios werden in Abbildung 3.3 dargestellt.

28 Kapitel 3. Anforderungsanalyse 23 Prototyp Benutzer 1: Tracing mit AOP wählen 1.1: GUI-Komponente anzeigen 2: erforderliche Daten eingeben 3: Beobachtungsfilter einstellen 2.1: Dateneingabe überprüfen 3.1: Statische Struktur analysieren 4: Tracing starten 3.2: Statische Struktur präsentieren 4.1: Aspektcode generieren 4.2: Aspectcode und fachlicher Code verweben Java-Anwendung 4.3: Java-Anwendung starten 5:[Aktion!= Ende-Aktion] //Aktion ausführen 6: Tracingdaten an den Prototyp senden 6.1: Tracingdaten anzeigen 7: Java-Anwendung beenden 7.1: Anwendung beenden 8: Tracingdaten speichern Abbildung 3.3 Szenario: Tracing mit AOP

29 Kapitel 3. Anforderungsanalyse Szenario: Tracing mit JPDA Die Szenarios werden in Abbildung 3.4 dargestellt und basieren zum Teil auf der Arbeit im [Gae03]. Prototyp Benutzer 1: Tracing mit JPDA wählen 1.1: GUI-Komponente anzeigen 2: erforderliche Datenangaben eingeben 3: Beobachtungsfilter einstellen 2.1: Datenangaben überprüfen 3.1: Statische Struktur analysieren 3.2: Statische Struktur präsentieren 4: Tracing starten 4.1: VM-Instanz erzeugen VM der Java-Anwendung 4.2: Ereignisse (Filter) registrieren 4.3: Startklasse aufrufen 5:*[Aktion!= Ende-Aktion] //Aktion ausführen 6:[Ereigniss registriert] //Ereignis melden 6.1: Ereignis auswerten 7: Java-Anwendung beenden 6.2: Tracingdaten anzeigen 7.1: VM stoppen 8: Tracingdaten speichern Abbildung 3.4 Szenario: Tracing mit JPDA 1. Der Benutzer wählt den Tracing-Ansatz mit JPDA aus und gibt alle Datenangaben wie im Ober-Anwendungsfall Laufzeitverhalten aufzeichnen an. Der Prototyp zeigt dann die entsprechende GUI-Komponente an.

30 Kapitel 3. Anforderungsanalyse Der Benutzer kann mit der Filter-Taste einen Beobachtungsfilter definieren. Dafür analysiert der Prototyp die statische Struktur der Java-Anwendung und präsentiert sie dem Benutzer am Bildschirm. Mit dem Filter kann der Benutzer gezielt auswählen, welche Teile Pakete, Klassen und Methoden- der Java- Anwendung analysiert werden sollen. Hier kann der Benutzer die Startklasse (Klasse mit main Methode) angeben, die zum Starten der Java-Anwendung aufgerufen werden soll. 3. Um die Java-Anwendung zu starten, führt der Benutzer die Aktion Nr. 3 im Ober- Anwendungsfall aus. Der Prototyp erzeugt dann eine virtuelle Maschine und registriert den in Aktion Nr.2 definierten Filter. Anschließend wird die in Aktion Nr. 2 angegebene Startklasse aufgerufen und die Java-Anwendung ausgeführt. 4. Die Java-Anwendung meldet die internen Ereignisse über JPDA an den Prototyp. Der Prototyp wertet die ankommenden Ereignisse aus und präsentiert sie dem Benutzer am Bildschirm. 5. Der Benutzer kann die Aktionen Nr.4 & 5 im Ober-Anwendungsfall ausführen. 3.6 Szenario: Tracingdaten auswerten Prototyp Benutzer 1: Aufgezeichnete Tracedaten laden 1.1: XML-Datei parsen 2: Tracedaten anhand einer Zeitmarke suchen 1.2: Tracedaten präsentieren 2.1:[Treffer gefunden] //Treffer anzeigen 3: Manuelle Zeit-Synchronisierung 2.2:[Treffer nicht gefunden] //Meldung anzeigen 4: Suchen aktualisieren 4.1:[Treffer gefunden] //Treffer anzeigen 4.2:[Treffer nicht gefunden] //Meldung anzeigen Abbildung 3.5 Szenario: Tracingdaten auswerten

31 Kapitel 3. Anforderungsanalyse 26 Der in Abbildung 3.5 dargestellte Anwendungsfall Tracingdaten auswerten wird durch folgende Szenarios beschrieben. 1. Der Benutzer wählt aufgezeichnete Tracingdaten aus, indem er die entsprechende XML-Datei mit dem Prototyp öffnet. Der Prototyp analysiert anschließend die XML-Datei und präsentiert sie dem Benutzer geeignet am Bildschirm, sodass der Benutzer die Daten komfortabel positionieren kann. 2. Der Benutzer kann anhand einer Zeitmarke (Stunde: Minute: Sekunde: Millisekunde) die gewünschte Tracingdaten-Eintragung suchen. Bei der Betätigung der Taste Suchen wird der Prototyp die in dieser eingegebenen Zeit aufgezeichnete Daten-Eintragung suchen und das Ergebnis dem Benutzer präsentieren. Wenn für die eingegebene Zeit kein Treffer gefunden ist, wird die naheliegendste Eintragung gezeigt oder der Prototyp zeigt eine Meldung, dass es keinen Treffer gefunden wurde. 3. Für die manuelle Zeit-Synchronisierung kann der Benutzer eine Offsetzeit (Stunde:Minute: Sekunde: Millisekunde) angeben. Der Benutzer kann mit der Taste Suchen das Suchergebnis aktualisieren. 4. Mit der Taste Paket-Filter kann der Benutzer die am Bildschirm präsentierten Tracingdaten nach Java-Paketgruppen filtern.

32 Kapitel 3. Anforderungsanalyse Funktionale Anforderung Im vorangehenden Abschnitt wurde ein Überblick über die Funktionalität des Systems aus Sicht des Benutzers gegeben. Dies genügt jedoch nicht um die Anforderungen an das System vollständig zu beschreiben. Jeder Anwendungsfall ist ein in sich geschlossenes Szenario des Verhaltens eines Benutzers, welches ohne den Gesamtzusammenhang des Systems betrachtet wurde. In diesem Abschnitt werden die Anforderungen beschrieben, die nicht direkt in einem Anwendungsfall sichtbar werden, sondern von allgemeiner Gütigkeit sind. Die funktionalen Anforderungen ergeben sich hauptsächlich aus den im Abschnitt 3.1 aufgelisteten Anwendungsfällen und beschreiben die Funktionalität des Prototyps und die Operationen, die dieser erfüllen soll. Es wird dabei zwischen grundlegenden (must have) und ergänzenden Funktionen (nice to have) unterschieden. Im groben umfassen diese die folgenden Punkte (siehe Tabelle 3-1): Nr Funktionale Anforderung 1 Aufzeichnung des systeminternen Verhaltens (Tracing) Kriterium 2. Die Interaktionen zwischen dem Benutzer und der zu analysierenden Java-Anwendung lösen intern Nachrichtenverkehr durch das Versenden von Botschaften zwischen Objekten aus. Der Prototyp soll zur Laufzeit relevante Vorgänge (Methodenaufrufe) auf der Anwendung beobachten und aufzeichnen, so dass eine Rekonstruktion des systeminternen Verhaltens in zeitlicher Reihenfolge ihres Auftretens für eine spätere Auswertung möglich wird. Folgende drei Tracing-Ansätze sollen je nach Möglichkeit implementiert werden: Code-Instrumentierung Aspektorientierte Programmierung Java Platform Debugger Architecture Erfassung der Screenshots Bei bestimmten Ereignissen und Zustandsänderungen der Benutzeroberfläche der zu analysierenden Java-Anwendung soll ein Schnappschuss des Bildschirmfotos der Benutzeroberfläche erfasst werden und in einer Datei (GIF-Format) gespeichert werden. Diese Funktionalität sollte mit der modifizierter Java-Laufzeit-Bibliothek oder AOP realisiert werden.

33 Kapitel 3. Anforderungsanalyse Aufzeichnen der Audio-Kommentare des Benutzers Die Kommentare des Benutzers werden aufgenommen und anschließend in das MPEG Layer 3 Format komprimiert. Auswertung der aufgezeichneten Tracingdaten Die Tracingdaten sollen anhand einer Zeitmarke (Minuten: Sekunde: Millisekunde + Offsetzeit) referenziert werden können. Die Tracingdaten sollen geeignet dargestellt werden, so dass man eine gezielte Information in der zeitlichen Reihenfolge ansehen kann (z.b. Blättern-Funktion ). Die angezeigten Methodenaufrufe sollen nach Paketgruppen (Package) gefiltert werden können. Wird beispielsweise vom Benutzer ein bestimmtes Tracingdatum ausgewählt, soll die Position der in dieser Zeit ausgeführten Methode im Eclipse-Java-Editor mittels Eclipse-PlugIn in der entsprechenden Klasse markiert werden. Es soll auch über die Zeitmarke möglich sein, die entsprechende Bild-/Audio-Datei automatisch zu öffnen. Sprachunabhängigkeit der aufgezeichneten Tracingdaten Die aufgezeichneten Tracingdaten sollen im XML-Format gespeichert werden, damit sie flexibel zwischen den verschiedensten Plattformen austauschbar sind. Schnittstelle für die anderen Programmiersprachen In der Zukunft soll der Prototyp in der Lage sein, entfernte Methodeaufrufe von Client-Anwendungen, die in anderen Programmiersprachen wie beispielsweise C# implementiert wurden, Dienste zur Verfügung zu stellen. Die Architektur des Prototyps soll nach Möglichkeit für diese Erweiterung entworfen werden. Legende: Musskriterien Wunschkriterien Tabelle 3-1 Funktionale Anforderungen an den Prototyp Die Musskriterien beschreiben Anforderungen, die für das Produkt unabdingbar sind, damit es für den vorgesehenen Einsatzzweck verwendet werden kann. Bei den Wünschkriterien handelt es sich um Anforderungen, die nicht unabdingbar sind, de-