Laufzeitanalysen mit Hilfe der Aspektorientierten ... - Feldschmid

Abschlussdokument
Aspektorientierte Programmierung
Alexander Burgess
Andreas Feldschmid
Henrik Kemmesies
Abdol Gholam
Pierre Chavaroche
21. Januar 2008

Name
Arbeitspaket
Pierre Chavaroche Kapitel 1 + 2
Henrik Kemmesies Kapitel 3 + Abschlussdokument
Andreas Feldschmid Kapitel 4 + 6.5
Abdol Gholam Kapitel 5
Alexander Burgess Kapitel 6
2

Inhaltsverzeichnis
1 Was ist die Motivation AOP zu nutzen? 5
2 Grundlagen AOP 7
2.1 Begriffe, Grundkonzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Das allgemeine Prinzip von AOP . . . . . . . . . . . . . . . . . . 7
2.1.2 Was genau ist ein Aspekt? . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3 Was ist ein Join-Point? . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.4 Was ist ein Pointcut? . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.5 Wo kann ich den nun den zusätzlichen Code definieren? (Advice) 11
2.1.6 Was ist eine Intertype-Declaration? . . . . . . . . . . . . . . . . . 12
2.2 Vorstellung und Einrichtung der Entwicklungstools . . . . . . . . . . . . 12
3 Laufzeitanalyse mit Hilfe von AOP 13
3.1 Laufzeitinformationen über Programme . . . . . . . . . . . . . . . . . . . 14
3.2 Erhebung von Laufzeitinformationen über Aspekte . . . . . . . . . . . . 16
3.3 Grenzen der Laufzeitinformationsbeschaffung . . . . . . . . . . . . . . . . 18
3.4 Anwendungsmöglichkeiten mit Laufzeitinformationen . . . . . . . . . . . 19
4 Entwurf eines prototypischen Werkzeugs 20
4.1 Architektur des Programms / Entscheidungen . . . . . . . . . . . . . . . 20
4.2 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3 Implementierte Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5 Einbinden benutzerspezifischer Aspekte in den Prototyp 29
6 Benutzung des Prototyps 34
6.1 Was leistet das Programm? . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2 Wie benutzt man das Programm? . . . . . . . . . . . . . . . . . . . . . . 34
6.3 Einbinden in ein Eclipseprojek . . . . . . . . . . . . . . . . . . . . . . . . 35
6.4 Einbinden über den Codeweaver . . . . . . . . . . . . . . . . . . . . . . . 36
6.5 Ausführen mittels Ant-Task . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.6 Was wird Ausgegeben? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Literaturverzeichnis 42
Abbildungsverzeichnis 43
3

Listings 44
4

1 Was ist die Motivation AOP zu
nutzen?
Eine der großen Herausforderungen der heutigen Softwareentwicklung ist es, die verschiedenen
Verantwortlichkeiten und Aufgaben einer Software und ihrer Komponenten sauber
zu trennen (Das Prinzip des ”
Seperation of Concerns“). Nur so können Abhängigkeiten
minimiert und eine lange Lebensdauer der Software garantiert werden.
Allerdings gibt es oft nicht-funktionale Anforderungen, die über den gesamten Code
verteilt sind (Die sogenannten ”
Crosscutting Concerns“).
Abbildung 1.1: Logging in Apache Tomcat
Wie man in Abbildung 1.1 sehen kann, ist das Logging über fast alle Module der Software
verstreut, da es offensichtlich oft benötigt wird. Obwohl es nur eine einzige Anforderung
(bzw. Aufgabe) ist, muss für die Realisierung Code in vielen Moduln geändert werden.
Weitere Beispiele für Crosscutting Concerns sind:
• Exception-Handling
• Performance
• Security
5

Abbildung 1.2: XML-Parsing in Apache Tomcat
Das Gegenbeispiel stellt Abbildung 1.2 dar: Das XML-Parsing ist nur in einem einzigen
Modul vertreten.
Eine Verteilung über den gesamten Softwarecode (wie in Abbildung 1.1) hat zur Folge,
dass
1. eine Änderung jener Anforderungen gleichzeitig eine Änderung an mehreren Stellen
im Code nach sich zieht (Fehlergefahr und geringe Produktivität).
2. der eigentliche, fachliche Code kaum mehr zu lesen ist, da er völlig von nichtfunktionalen
Anforderungen durchsetzt ist.
Doch wie kann AOP hier jetzt helfen? Die Aspektorientierte Programmierung hat es sich
zur Aufgabe gemacht, diese Crosscutting Concerns vom eigentlichen, fachlichen Code zu
kapseln und somit zu trennen.
6

2 Grundlagen AOP
AOP ist ein mächtiges Werkzeug. Wir möchten hier noch einmal kurz die wichtigsten
Konzepte von AspectJ vorstellen. Für genauere Einblicke können wir unsere Einführungs-
Präsentation zum Thema AOP bzw. die AspectJ-Dokumentation unter [Aspb] sowie die
Bücher [Lad03] und [Böh06] empfehlen.
2.1 Begriffe, Grundkonzepte
Wie in den meisten anderen Techniken, gibt es auch in AOP einige Begriffe und Konzepte
zu erklären, bevor man mit AOP wirklich arbeiten kann. Die Prinzipien sind aber, einmal
verstanden, sehr schlüssig.
2.1.1 Das allgemeine Prinzip von AOP
Eine grobe Übersicht wie AOP funktioniert, sieht man in Abbildung 2.1. Links ist mit
Methode1 und Methode2 ein sequentieller Programmablauf vorzufinden, wie man es aus
Programmen gewöhnt ist. Nun gibt es in diesem Programmablauf bestimmte Punkte
(Die Join-Points) an denen jetzt zusätzlicher Code hinzugefügt werden könnte. Dieser
zusätzliche Code ist in sogenannten Aspekten gekapselt. Der Pointcut wählt diejenigen
Joinpoints aus, an welchen zusätzlicher Code hinzugefügt werden soll. Das Hinzufügen
des Codes an die ausgewählten Joinpoints wird in AOP ”
Weaving“ (Verweben) genannt.
7

Abbildung 2.1: Wo AOP angreift
2.1.2 Was genau ist ein Aspekt?
Ein Aspekt ist einer Java-Klasse sehr ähnlich: Er besitzt genauso Methoden und Variablen
wie man es von einer Java-Klasse gewöhnt ist. Ein Aspekt enthält aber zusätzliche
Komponenten um die AOP-Techniken anwenden zu können. In AspectJ kann einem die
Syntax für einen Aspekt sehr bekannt vorkommen:
Listing 2.1: Ein Aspekt in AspectJ
public aspect KontoAspekt
[ implements ] [ extends ][ per−Klausel ]
{
//Code
}
Zusätzlich hat er die Endung .aj um sich von den normalen Java-Klassen zu unterscheiden.
8

2.1.3 Was ist ein Join-Point?
Join-Points sind über den gesamten Code verteilt. Es sind die Punkte, an denen der
Compiler die zusätzlichen Anweisungen aus den Aspekten ”
einweben“ kann. Aufgrund
dessen werden sie oft auch als ”
Webepunkte“ bezeichnet. Ein Java-Beispiel:
Abbildung 2.2: Eine Java-Klasse Konto mit Beispiel-Join-Points
Abbildung 2.2 zeigt, wo ein Join-Point sein kann: Bei der Instanziierung einer Klasse,
beim Ausführen einer Methode, beim Beschreiben einer Variablen, usw.
2.1.4 Was ist ein Pointcut?
Ein Pointcut fasst nun eine Menge von Join-Points zusammen und wird im jeweiligen
Aspekt definiert. Er kann keinen Join-Point enthalten, alle Join-Points oder im Idealfall
9

genau diejenigen, die man für seinen Aspekt benötigt. Sollte der Programmablauf zu
einem Join-Point kommen und der Pointcut enthält diesen, wird der zusätzliche Code
im Aspekt an dieser Stelle ausgeführt. Ein paar Java-Beispiele:
Allgemeine Syntax:
pointcut [ pointCutName ( ) ] : [ Auswahlmethode ] ;
Ein konkreter Pointcut, der einen Join-Point aus der Java-Klasse ”
Konto“ enthält:
pointcut KontoSelect ( ) : c a l l ( void Konto . abheben ( int ) ) ;
Sobald die Methode abheben aus der Klasse Konto ”
gecallt“ (d.h. aufgerufen) wird, setzt
der dafür vorgesehene zusätzliche Code ein.
Der selbe Pointcut mit einem logischen Operator, um einen zusätzlichen Join-Point zu
selektieren:
pointcut KontoSelect ( ) : c a l l ( void Konto . abheben ( int ) )
| | c a l l ( void Konto . e i n z a h l e n ( int ) ) ;
Der Pointcut trifft dann zu, wenn entweder die Methode abheben oder einzahlen aufgerufen
wird.
Diesmal mit Wildcards:
pointcut KontoSelect ( ) : c a l l (∗ Konto . abheben ( . . ) ) ;
Sollte es Überladungen der Methode abheben geben, sind diese durch den Pointcut ebenfalls
betroffen.
Anmerkung: Logische Operatoren und Wildcards können kombiniert werden.
Neben der Pointcut-Methode call gibt es noch viele weitere Methoden:
• execution(Methoden- oder Konstruktorname)
• handler(Exception)
• args(Parameter)
• this(Instanzenname)
• get(Variable)
• set(Variable)
Dies sind nur Einige unter vielen Weiteren, worauf hier aber nicht näher eingegangen
wird.
10

2.1.5 Wo kann ich den nun den zusätzlichen Code definieren?
(Advice)
Abbildung 2.3: Der Advice
In Abbildung 2.3 sieht man die Rolle des Advice: Er befindet sich ebenfalls im Aspekt
und enthält den Code, der an einem Join-Point ausgeführt werden soll.
Beispiel für einen Advice:
b e f o r e ( ) : KontoSelect ( )
{
System . out . p r i n t l n ( ”Es wird etwas von einem Konto abgehoben ! ” ) ;
}
Bevor die Methode Konto.abheben (definierter Join-Point im Pointcut KontoSelect() )
aufgerufen wird, wird eine System.out.-Meldung ausgegeben. Neben before gibt es auch
11

noch after (Ausführung nach einem Join-Point) und around (umschließt einen Join-
Point, bzw. kann ihn auch ersetzen).
2.1.6 Was ist eine Intertype-Declaration?
Mit der Intertype-Declaration ist es sogar möglich, zusätzliche Variablen und Methoden
bestehenden Klassen hinzuzufügen.
Beispiel:
public aspect ZusatzAttribut {
private int Konto . z i n s s a t z = 2 ;
}
public int Konto . g e t Z i n s s a t z ( ) {
return z i n s s a t z ;
}
Im Aspekt ZusatzAttribut wird der Klasse Konto ein weitere Variable hinzugefugt: Der
Zinssatz. Zusätzlich erhält sie eine Get-Methode.
2.2 Vorstellung und Einrichtung der
Entwicklungstools
Wie auch schon für die Beispiele aus Kapitel 1, haben wir für unser Projekt den Standard
AspectJ gewählt. Der Vorteil von AspectJ ist die Aufwärtskompatibilität: Somit
ist korrekter Java-Code auch korrekter AspectJ-Code. Zusätzlich erzeugt der AspectJ-
Compiler ganz normalen Java-Bytecode, d.h. es läuft auf unveränderter JVM und ist
somit auch Plattformkompatibel.
Die Integration in Eclipse funktioniert wie folgt: Unter http://www.eclipse.org/ajdt/
findet man die neusten AJDT (AspectJ Development Tools). Laden Sie sich hier die
entsprechende .zip-Datei herunter. Anschließend kopieren Sie die Dateien aus dem Ordner
”
features“ und ”
plugins“ in die gleichnamigen Ordner aus Ihrem Eclipse-Verzeichnis.
Natürlich ist eine Installation auch automatisch über die Eclipse Update-Funktion möglich
(die Update-Site URL ist auch auf der AJDT-Seite zu finden).
12

3 Laufzeitanalyse mit Hilfe von
AOP
Wo gehobelt wird, da fallen Späne“ - und wo programmiert wird, da entstehen Fehler.
”
Dieser schlaue Satz dürfte jedem heranwachsenden Informatiker wohlbekannt sein. Bei
Unachtsamkeit können Fehler zu finanziellen oder sogar im schlimmsten Fall zu menschlichen
Verlusten führen. Allein im Jahr 1999 verlor die NASA 125 Millionen Dollar durch
einen verpassten Mars-Landeanflug der Sonde Mars Climate Orbiter“. Der Grund: Eine
”
fehlerhafte Implementierung des Maßsystems [Mar].
Zur Vermeidung solcher Programmierfehler kennt die Informatik eine Antwort: Softwaretests.
Noch bevor eine Software den Unit-Tests unterzogen wird, sollte sie einer
statischen Code-Analyse unterzogen werden. Die statische Code-Analyse überprüft den
Quelltext eines Programms auf eine Reihe vorher festgelegter Regeln. Dadurch können
beispielsweise folgende Fälle identifiziert und behoben werden:
• fehlende Vorinitialisierung von Variablen
• Identifikation von unerreichbaren Codestellen
• Überschreitung der maximalen Lines of Code (LoC) einer Methode
• fehlendes Implementieren eines Interfaces
Teilweise wird die statische Analyse durch die Zuhilfenahme von Stylecheckern ergänzt,
die den Quelltext auf vorher festgelegte Programmierstile überprüfen.
Die statische Code-Analyse hat allerdings den Nachteil, dass Programmierfehler, die
erst während der Programmausführung ”
entstehen“, nicht als solche identifiziert werden
können. Um diesem Problem entgegenzuwirken muss das Programm zur Laufzeit, durch
eine dynamische Code-Analyse, analysiert werden. Hierbei sind nicht nur Informationen
an einer ganz bestimmten Programmstelle von Interesse, sondern auch der allgemeine
Zustand und der Ablauf des Programms können eine wichtige Rolle spielen.
Dynamische Informationen über ein laufendes Programm nennt man Laufzeitinformationen.
Sie können mit Hilfe der Aspektorientierten Programmierung aus dem Programmfluss
herausgeholt werden. Bevor dies allerdings durchgeführt werden kann, muss
zunächst überlegt werden, welche Laufzeitinformationen eines Programms überhaupt
von Interesse sind.
13

3.1 Laufzeitinformationen über Programme
Generell muss bei dem Begriff ”
Laufzeitinformationen“ von einem unbekannten Projekt
ausgegangen werden. Ein Projekt ist dann unbekannt, wenn der innere Aufbau und die
innere Funktionsweise unbekannt sind. Man spricht in diesem Fall von einer Blackbox.
Abbildung 3.1: Blackbox-Ansicht eines Projekts
Betrachtet man nun eine Blackbox, wie sie in der Abbildung 3.1 zu sehen ist, so beginnt
man automatisch, sich Fragen über das vorliegende Objekt und dessen Laufzeitinformationen
zu stellen. Mögliche Laufzeitinformationen werden nun im Folgenden strukturiert
erfasst. Als Grobeinteilung wurden die Strukturierungspunkte Klassen, Methoden, Einund
Ausgaben, Threads, Exceptions, Technisches und Sonstiges gewählt:
• Klassen
– Zählen der Instanzen einer bestimmten Klasse
– Einhalten vorgeschriebener Schnittstellen
– Korrektes Abbilden der Instanzen auf die vorgegebene Softwarearchitektur
– Rekonstruierung der Softwarearchitektur
– Ermittlung der Aufrufreihenfolge der Komponenten
(ruft obere immer untere auf?)
• Methoden
– Ermittlung der Anzahl der Aufrufe einer Methode
– Messung der Ausführungszeit einer Methode
– Auffinden von ungenutzten Methoden
– Auffinden von ungenutzten Argumente
14

• Threads
– Auffinden vorhandener Threads
– Ermittlung der Anzahl von Threads zu einem gewissen Zeitpunkt
– Ermittlung der Anzahl von Threads über den Gesamtablauf des Programms
– Messen der Ausführungszeit eines Threads
– Ermittlung der Größe der zugeteilten Zeitscheibe an einen Thread
– Auffinden von ungenutzten Threads
– Auffinden von Deadlocks
– Messen der Wartezeit eines Threads auf gesperrte Objekte
• Ein- und Ausgaben
– Erfassen von Logging-Informationen
– Erfassen von gelesenen und geschriebenen Inhalten einer Datei
– Verwendung von Dateien
– Erfassen der Anzahl von verwendeten Dateien
– Korrektes Öffnen und Schließen der Dateien
– Verwendung von Netzwerkverbindungen
– Ermittlung der Verwendungsdauer externer Quellen
(Dateien und Netzwerkverbindungen)
– Ermittlung von verschickten Informationen über das Netzwerk
– Erfassung von Benutzereingaben (Konsole / GUI)
• Exceptions
– Ermittlung aller geworfenen Exceptions
– Auffinden unvorhergesehener Exceptions
– Ermittlung der Anzahl und des Zeitpunkts von geworfenen Exceptions
• Technisches
– Ermittlung der Anzahl benötigter Speicherzellen
(im Hinblick auf Embedded Systems)
– Ermittlung der Speicheradresse von Variable X
– Messen der Speicherbelastung des Programms
– Ermittlung der Belegungenen der Prozessorregister
– Auffinden von fehlenden Speicherfreigaben
• Sonstiges
– Protokollierung des detaillierten Programmablaufs
(Wann hat Benutzer was gedrückt?)
15

– Erkennung von Endlosschleifen
– Ausgeben von SQL-Statements
– Ermittlung des Ausführungsorts des Programms
– Ermittlung des Bauplans der GUI
– Zählen von GUI-Elementen
Hinweis: Diese Liste hat nicht die Anforderung vollständig zu sein. Sie soll lediglich
einen Überblick über mögliche Laufzeitinformationen geben.
3.2 Erhebung von Laufzeitinformationen über
Aspekte
Nachdem nun ein Überblick über mögliche Laufzeitinformationen erstellt wurde, sind
diese nun aus dem Black-Box-Programm zu extrahieren. Dazu wird im Weiteren die
Laufzeitinformation ”
Ausgeben von SQL-Statements“ als Erklärungsbeispiel herangezogen.
Wie bereits zu Beginn dieses Kapitels erwähnt, verschafft AOP mit Hilfe der Aspekte die
Möglichkeit, dieses Vorhaben umzusetzen. Das Black-Box-Projekt muss dazu im ersten
Schritt in ein AspectJ-Projekt umgewandelt werden. Dies geschieht durch die Auswahl
des Menüpunktes ”
Rechtsklick auf den Black-Box-Projektordner“ −→ ”
AspectJ Tools“
−→ ”
Convert to AspectJ Project“.
Abbildung 3.2: Umwandlung eines Java-Projekts in ein AspectJ-Project
Anschließend sollte in dem Black-Box-Projektordner ein neues Package für die zu implementierenden
Aspekte erstellt werden. In dem Aspekt-Package muss nun im zweiten
Schritt ein Aspekt erstellt werden. Der Aspekt wird über ”
Rechtsklick auf Aspekt-
Package −→ New −→ Other. . . −→ AspectJ −→ Aspect“ mit einem beliebigen Namen
16

erstellt. Ein Aspekt ist grundsätzlich ein Behälter für AOP-Code und am ehesten mit
einer Java-Klasse zu vergleichen – nur dass der Aspekt statt *.java auf *.aj endet.
Nach der Erstellung des Aspekts, ist in der *.aj-Datei bereits folgender Code enthalten:
Listing 3.1: Die erste Codezeile vom Aspekt SqlStatementsAspect
public aspect SqlStatementsAspect { . . . }
Nun muss geklärt werden, welche Sprachkonstrukte die gesuchte Laufzeitinformation
charakterisieren. Diese Charakterisierung ist besonders für die Erstellung der Join-Points
wichtig. Im Fall der ”
Ausgeben von SQL-Statements“-Laufzeitinformation genügt ein
kurzer Blick in die Java-Dokumentation im Abschnitt java.sql.Statement unter http://
java.sun.com/javase/6/docs/api/java/sql/Statement.html , woraus hervor geht,
dass jedes SQL-Statement unter JDBC über eine der execute*-Methoden des Statement-
Interfaces abgesetzt wird (die addBatch()-Methode wird hier ignoriert).
Anschließend kann durch diese Charaktereigenschaften der Pointcut mit seinen Join-
Points definiert werden (in unserem Laufzeitinformationen-Fall existiert nur ein Join-
Point!). Dazu wird zuerst der Pointcut mit einem Namen und einem abschließenden ”
:“
angegeben, gefolgt von den Join-Point-Definitionen:
Listing 3.2: Pointcut- und Join-Point-Definition im Aspekt SqlStatementsAspect
pointcut getSqlStatement ( S t r i n g s q l ) :
c a l l (∗ java . s q l . Statement . execute ∗ ( . . ) ) && args ( sql , . . ) ;
Sollen weitere Join-Points angegeben werden, so geschieht dies durch das Anhängen des
Oder-Operators ‖ an den ersten Join-Point (nach ”
&& args(sql, ..)“ ), gefolgt von den
weiteren Join-Point-Definitionen. Um nicht jede der execute*-Methoden einzeln angeben
zu müssen, können Wildcards eingesetzt werden. Ein Stern * steht für eine beliebige
Anzahl beliebiger Zeichen (außer dem Punkt). Zwei Punkte .. stehen für eine beliebige
Anzahl von beliebigen Zeichen (einschließlich dem Punkt) und ein Plus + steht für
sämtliche Unterklassen bzw. Interfaces des vorgegebenen Typs. Ist zusätzlich der Zugriff
auf die Argumente einer Methode nötig, so muss das Schlüsselwort ”
args“ mit Angabe
der erwarteten Argumente dem Join-Point hinzugefügt werden.
Nachdem der Einstiegspunkt unserer Interessen definiert ist, muss nun der auszuführende
Code an dieser Stelle definiert werden. Dies wird in einem before-, after- oder einem
around-Advice mit Angabe des Pointcuts festgelegt:
Listing 3.3: Advice-Definition im Aspekt SqlStatementsAspect
b e f o r e ( S t r i n g s q l ) : getSqlStatement ( s q l ) {
System . out . p r i n t l n ( ”SQL−Statement ’ ”+s q l+” ’ was c a l l e d ” ) ;
}
17

Wurde alles richtig implementiert, so wird in der Entwicklungsumgebung ”
Eclipse“ links
neben dem Aspekt ein kleiner Pfeil angezeigt, der beim Herüberfahren mit der Maus die
anvisierte Stelle im Black-Box-Projekt anzeigt.
Abbildung 3.3: Der Aspekt Ausgeben von SQL-Statements zeigt auf eine Codestelle
Umgekehrt wird bei der anvisierten Stelle im Black-Box-Projekt ein entgegengesetzter
Pfeil angezeigt:
Abbildung 3.4: Main-Methode, auf die der Aspekt Ausgeben von SQL-Statements zeigt
Allerdings sind der Erfassung der Laufzeitinformationen gewisse Grenzen gesetzt, die im
Folgenden untersucht werden.
3.3 Grenzen der Laufzeitinformationsbeschaffung
Mit AOP können keine echten Ausführungszeiten einer Methode oder eines Teilbereichs
des Programms ermittelt werden. Für eine Zeitmessung muss vor und nach dem zu
messenden Code zusätzlicher AOP-Code eingefügt werden. Dieser zusätzliche Code ist,
zusätzlich zum normalen Code, während der Programmausführung auszuführen, wodurch
wiederum zusätzliche Zeit beansprucht wird und somit das Gesamtergebnis einer
gemessenen Ausführungszeit verfälscht wird. Die mit AOP ermittelten Ausführungszeiten
18

sind daher immer nur Näherungswerte, die allerdings trotzdem gut für Vergleichszwecke
herangezogen werden können.
Mit AOP ist es zudem nicht möglich, den Code zwischen einem try- und catch-Block oder
den Ausführungsort eines Threads in einem Join-Point anzugeben. Auch das Erfassen
von technischen Informationen, wie z.B. die Anzahl der benötigten Speicherzellen für ein
Objekt, ist beim managed Code, wie z.B. Java, nicht möglich, da AOP ebenfalls wie der
managed Code nur in einer Sandbox abläuft und keinen Zugriff auf die Arbeitsweisen
der Virtual Machine hat.
3.4 Anwendungsmöglichkeiten mit
Laufzeitinformationen
Wurden einige Laufzeitinformationen aus einem Programm mit den entsprechenden
Aspekten extrahiert, so stellt sich nun die Frage, wie diese weiterzuverarbeiten sind.
Ein besonders wichtiger Anwendungsfall ist die Grundlagenbildung für einen Profiler.
Dieser müsste allerdings zusätzlich mit statischen Analysen ergänzt werden, um das
volle Spektrum der Softwareanalyse nutzen zu können.
Weiter könnten die Laufzeitinformationen für die Erstellung von Sequenzdiagrammen
oder zum Kennenlernen eines Programms verwendet werden. Unter Kennenlernen ist
hier zu verstehen, dass ein Entwickler die Aufgabe bekommen hat, eine ihm unbekannte
Software um gewisse Funktionalitäten zu erweitern / abzuändern ohne dabei auf Softwaredokumentation
oder früher beteiligte Entwickler zurückzugreifen. Durch entsprechende
Laufzeitinformationen könnten hier schnell und einfach die vorhandene Softwarearchitektur,
die dafür benötigt wird, und der Programmablauf der zu erweiternden Software
ermittelt werden.
Soll darüber hinaus ein Programm aufgrund schlechter Performance optimiert werden,
so könnte es sehr wichtig sein, die Methode mit der längsten Ausführungsdauer zu identifizieren.
Auch dies ist mit Laufzeitinformationen möglich.
Ebenfalls sind Laufzeitinformationen für das Testen von Software geeignet: Es wird vor
der Ausführung eines Programms abgeschätzt, wie lange eine gewisse Methode benötigen
darf. Danach wird die Software ausgeführt und die theoretisch ermittelte Zeit mit der
tatsächlichen Ausführungszeit verglichen. Unterscheiden sich diese Werte gravierend, so
könnte dies bereits ein Indiz für fehlerhaften Code sein. Eine weitere Möglichkeit des
Testens wäre eine eigene Implementierung, auf Basis von Laufzeitinformationen, für das
Tracen eines Programms.
Auch können Laufzeitinformationen zur Softwarequalitätsicherung der Softwarearchitektur
eingesetzt werden, indem die Soll-Architektur mit der tatsächlichen Implementierung
abgeglichen wird und dabei Komponenten überführt werden, die andere Komponenten
verbotener Weise übergehen.
19

4 Entwurf eines prototypischen
Werkzeugs
In diesem Abschnitt wird das von uns implementierte prototypische Werkzeug kurz
vorgestellt.
Gerade beim Profiling beziehungsweise der Analyse von Methodenlaufzeiten, muss viel
Wert auf Performance und Skalierbarkeit gelegt werden, damit ein möglichst unverfälschtes
Ergebnis erzielt werden kann. Die von uns implementierten Aspekte sowie die erstellte
Architektur wurden nicht speziell auf einen performanceorientierten oder gar skalierbaren
Ansatz optimiert. Die erstellte Lösung ist also eher als ”
Prototyp“ oder ”
Proof of
Concept“ zu verstehen – die generierten Ausgaben können als Richtwerte herangezogen
werden, sind aber auf jeden Fall kritisch zu hinterfragen.
4.1 Architektur des Programms / Entscheidungen
Um die Architektur des Programms verstehen zu können, ist es wichtig die Grundzüge
Aspektorientierter Programmierung zu verstehen – siehe dazu Kapitel 1.
Bei der Analyse der Architekturanforderungen an unser Programm wurde schnell klar,
dass eine der Hauptanforderungen die Interoperabilität ist, also die Möglichkeit unser
Werkzeug ohne große Anpassungen auf ein beliebiges Java-Projekt anwenden zu können.
Diese Funktion wird durch AspectJ und somit von den verschiedenen Aspekten von
Haus aus bestens Unterstützt – wir mussten also nur noch darauf achten beim Sammeln,
Verwalten und Ausgeben der Daten keine projektspezifischen Abhängigkeiten zu
generieren.
Um die Informationen, die von den einzelnen Aspekten gesammelt werden auswerten
und eventuell darstellen zu können, muss eine Ausgabe stattfinden. Dies könnte nun
per Ausgabe in eine Datei, Schreiben in eine Datenbank, auf einen Socket oder eine
MessageQueue realisiert werden. Wir entschieden uns der Einfachheit halber für eine
simple Ausgabe in eine Datei. Dabei entschieden wir uns für eine Ausgabe im XML-
Format. Auch dafür musste eine – soweit überhaupt möglich – gemeinsame Struktur
festgelegt werden. Einer der Gründe für das XML-Ausgabeformat war die Möglichkeit
das erzeugte XML-Dokument mittels XSLT in verschiedene andere Formate (z.B. CSV,
SVG, XHTML usw.) transformieren zu können.
20

Ein zusätzlicher wichtiger Punkt in diesem Kontext ist die Fragestellung, wann die Ausgabe
erfolgt. Bei jedem Funktionsaufruf mehrere XML-Java-Elemente zu erstellen und
diese dann in eine XML-Datei korrekt einzuschachteln würde eine – selbst für einen Prototypen
– zu hohe Beeinflussung der Laufzeit bedeuten. Selbst Ausgaben per System.out
beeinflussen die Laufzeit schon deutlich (Programmlaufzeit Normal: 6.5Sec, mit Aspekten
7Sec, mit System.out-Ausgabe bei jedem Methodenaufruf: 25Sec). Daher wurde
von uns eine Möglichkeit angestrebt die Informationen während dem Programmablauf
lediglich mittels Java-Objekten vorzuhalten und nach dem Beenden des eigentlichen
Programmablaufs die Transformation in XML-Objekte und die Datei-Ausgabe in eine
XML-Datei zu starten. Natürlich ergeben sich dadurch gewisse Constraints und Nachteile.
So steigt die Speichernutzung stärker an und sehr lang laufende Programme mit
vielen Methodenaufrufen führen letztendlich zum Speicherüberlauf. Um diese Nachteile
zu beseitigen, müsste eine ausgereiftere Logging-Methode benutzt werden, welche ständig
oder auch in bestimmten Intervallen die Log-Ausgabe in eine Logdatei startet und dabei
die Ausführung des zu profilenden Programms möglichst wenig beeinflusst.
Eine weitere Entscheidung, die wir Treffen mussten, war die Wahl der Zeitabstände
zur Methodenmessung. Sehr viele Methoden laufen äußerst kurz, so dass eine Messung
mit System.getCurrentTimeMillis jedes Mal 0ms ergeben hätte. System.nanoTime liefert
zwar nicht wirklich Zeiten mit Nanosekunden-Granularität, schafft aber durchaus
genauere Messungen als Millisekunden, zusätzlich ist System.nanoTime() nicht von der
Betriebssystem-Zeit abhängig, kann also nicht durch den User beeinflusst werden.
Eine sehr wichtige Funktion ist die Beschränkung des Profilings auf einen Teilbereich der
Applikation. So möchte man vielleicht nur die Datenbank-Schicht profilen, während der
Anwendungskern und die GUI nicht von Interesse sind. Dies konnte ebenfalls mit einer
AspectJ-Funktion gelöst werden: Pointcuts die within(Packagename..*) beinhalten treffen
nur auf Joinpoints zu, die im jeweiligen Package oder Unterpackage liegen (Wildcard-
Bedeutung siehe [Syn]). So konnten wir mit dem Pointcut excluded: !within(cleverTec..*)
auch festlegen, dass sich unsere Aspekte nicht gegenseitig profilen.
21

Abbildung 4.1: Die excluded-/included-Anweisung
Eine weitere Anforderung war es, die einzelnen Aspekte modular zu entwickeln, um
wenig oder keine Abhängigkeiten zwischen den Aspekten untereinander zu generieren.
Somit konnte die Implementierung unabhängig voneinander vonstatten gehen und so die
Arbeit besser aufgeteilt werden. Zusätzlich können die Aspekte dann auch einzeln zuoder
abgeschaltet werden und neue Aspekte ohne große Probleme hinzugefügt werden.
Letztendlich konnten wir die Architektur sehr simpel und überschaubar halten:
22

Abbildung 4.2: Die technische Architektur des Prototyps
Wie man sieht, wird ein AbstractAspect verwendet, in welchem zum einen die angesprochenen
Pointcuts excluded()/included() vorhanden sind – welche von jedem konkreten
Aspekt später auch für jeden Pointcut benutzt werden müssen – und zum anderen
die Verbindung zum Logger, also der Datenhaltung hergestellt wird. Dabei wird keine
Schnittstelle verwendet, sondern der Logger direkt übernommen. Dies bedeutet, dass bei
einem Austausch des Loggers sämtliche Aspekte an den neuen Logger angepasst werden
müssen – dies nehmen wir aber in Kauf, da bei einer Umstellung des Loggers auf eine
andere, performantere Methode gleich die gesamte Architektur sowie die Struktur der
ValueObjects neu überdacht werden muss.
4.2 Implementierung
Bei der Implementierung starteten wir damit, unsere Loggerklasse zu schreiben. Der Logger
ist dafür zuständig die Logdaten aufzunehmen und nach Ablauf des zu überwachenden
Programms auszugeben.
23

Zur Datenhaltung innerhalb des Loggers entschlossen wir uns parametrisierte, geschachtelte
Maps zu verwenden. Im Logger selbst finden wir eine Map, welche aus String/-
Map als Key/Value Paaren besteht (Map). Jeder
Aspekt nutzt die vom Logger angebotene Methode ”
Map
getHashMap(String)“, um eine exklusive Map zu bekommen – dafür übergibt man als
String-Parameter Aspektname.class.getName(), um so eine Eindeutigkeit zu erlangen.
In diese Map schreibt der Aspekt dann seine Daten als String, ValueObject-Paare.
Die nächste Funktionalität die wir implementieren wollten, war die Ausgabe der Daten
nach Ablauf des zu überwachenden Programms. Dies gestaltete sich als etwas schwieriger.
Wie wird man darüber Informiert, dass das Programm beendet ist? Wenn es sich um ein
rein linear ablaufendes Programm handelt, könnte man am Ende eine Benachrichtigung
einbauen, dazu müsste das Programm aber geändert werden, was wir eigentlich vermeiden
wollten. Eine andere Möglichkeit wäre die finalize()-Methode unseres Loggers zu
überschreiben. Jedes Objekt in Java besitzt die von Object geerbte finalize()-Methode.
Diese wird aufgerufen, sobald das jeweilige Objekt explizit - also vom GarbageCollector
- entfernt wird. Wann und ob Objekte vom GarbageCollector entfernt werden, ist aber
nicht festgelegt. Wird das Programm beendet, werden alle noch existierenden Objekte
zerstört, wobei die finalize()-Methode aber nicht ausgeführt wird.
Eine bessere Möglichkeit bietet ein sogenannter ShutdownHook.
Per Runtime.getRuntime().addShutdownHook(Thread t); wird ein Thread in der Runtime
registriert, welcher ausgeführt wird, sobald exit(int) aufgerufen wird, keine weiteren
aktiven Threads mehr am Leben sind oder die VirtualMachine vom Benutzer terminiert
wird (Logoff z.B.), also kurz gesagt das Programm beendet wird. Durch diesen Mechanismus
ist es uns möglich relativ einfach und zuverlässig die Ausgabe erst nach Beenden
des Hauptprogramms zu starten.
Die verschiedenen Aspekte erheben unterschiedliche Daten, teilweise werden nur String/Integer
Paare gespeichert (z.B. zählen der Instanzen einer Klasse), andere speichern zu
einem String mehrere Zeit-Intervalle mit Anfangs und Endzeit sowie zusätzliche Informationen,
wie etwa die mittlere Ausführungszeit. Die Struktur und das Ausgabeformat
der einzelnen Aspektdaten unterscheiden sich also stark untereinander und sind auch
nicht generisch darstellbar. Daher entwickelten wir unser ValueObject Interface. Das
Interface beinhaltet zwei Methoden:
• public void printValues();
//Gibt die Daten auf System.out aus – Debugging Zwecke etc.
• public Element toXMLElement();
//Gibt ein JDOM-Element zurück, in welchem die gesamten Daten als XML-
Sturktur vorhanden sind
Wie die Implementierung des ValueObjects ansonsten aufgebaut ist und wie es seine
mehr oder weniger komplexen Daten hält, interessiert uns hier nicht – das ist der Aufgabenbereich
des einzelnen Aspekts.
24

Unser Logger, welcher ja als ShutdownHook-Thread registriert ist, kann nun zunächst
über die erste Map iterieren und erhält so für jeden Key – welcher ja einem Aspekt-
Package entspricht – als Value eine Map aus String, ValueObjects. Nun kann er über diese
String-, ValueObjects-Paare iterieren und die toXMLElement()-Methode des ValueObjects
benutzen, um so die gesamten Daten für einen Aspekt zu aggregieren. So entsteht
dann aus den einzelnen XML-Teilbäumen ein großes XML Gesamtdokument. Dieses liegt
nun als JDOM-Document vor und kann direkt mit dem org.jdom.output.Outputter in
eine Datei geschrieben werden.
Nachdem dies geschehen ist, wird überprüft, ob in der clevertec.properties XSLT-Stylesheets
angegeben wurden. Gegebenenfalls wird das JDOM-Document dann mit diesen
XSLT-Stylesheets transformiert und die Ausgaben in die entsprechenden Dateien geschrieben.
So liefern wir z.B. Templates für das erzeugen von CSV-Dateien, welche dann
in Excel weiterverarbeitet werden können, z.B. sortieren, selektieren und erstellen von
Charts, etc. Eine dieser CSVs wurde auch vom Team RoQuMod weiterverwendet: Es
wurde ein conqat-Prozessor geschrieben, welcher das CSV einliest und so die Werte in
Conqat als Daten verfügbar macht und letztendlich als Tabelle ausgibt. Die erzeugten
SVG-Grafiken sind eine Art ”
Proof of Concept“, dass man unsere Daten auch visualisieren
kann.
Der gesamte Ablauf kann etwa folgendermaßen dargestellt werden:
25

Abbildung 4.3: Programmablauf des Prototypen
4.3 Implementierte Aspekte
Folgende Aspekte haben wir in der aktuellen Version des Programms implementiert:
• ExceptionsAspect: Zählt wie oft Exceptions aufgetreten sind und wann
26

• Instances: Zählt wie viele Objektinstanzen erzeugt werden
• MethodExecutionNumber: Zählt wie oft Methoden aufgerufen wurden
• MethodExecutionRuntime: Misst die Zeit, die für eine Methodenausführung benötigt
wird
• MethodCallRuntime: Wie MethodExecutionRuntime, nur für Calls, standardmäßig
disabled da sonst sehr viele Logdaten entstehen!
• ThreadCreation: Zählt wieviele Threads erzeugt wurden
• ThreadStartup: Zählt wie viele Threads ausgeführt / beendet wurden
Die Aspekte konnten alle unabhängig voneinander implementiert werden. Teilweise wurden
gemeinsame Utility-Klassen benutzt, z.B. für das Festhalten von Zeitintervallen.
Beispielsaspekt: Instances.aj
Exemplarisch möchten wir hier nun einen Aspekt noch mal etwas genauer betrachten:
Der Aspekt Instances.aj zählt alle Objektinstanzen.
Der Aspekt leitet sich – wie jeder Aspekt – von unserem AbstractAspect ab. Dadurch
erbt er die beiden Pointcuts included && excluded und den Logger log. Nun wird aus
dem Logger eine für diesen Aspekt exklusive Map geholt. Dafür wird der Aspektname.class.getName()
– also die Packagestruktur und der eigentliche Aspektname – an
die Methode Logger.getHashMap(String) übergeben. In der Ausgabe wird später eine
Section für diesen Aspekt erstellt, die der Packagestruktur entspricht – hier also ”
clever-
Tec.aspects.instanceCounter“. Dies bedeutet, wenn man zwei Aspekte in einem Package
implementieren würde, würden ihre Daten in der gleichen Sektion der XML-Ausgabe
landen.
Als nächstes muss ein oder mehrere Pointcuts definiert werden. Dabei ist darauf zu achten
”
&& excluded() && included()“ an den Pointcut anzufügen, damit sich die Aspekte
nicht gegenseitig ”
matchen“ und zusätzlich eine Einschränkung der Analyse auf Teilbereiche
möglich ist. In unserem Fall sieht der Pointcut so aus:
pointcut InstancesCount ( ) :
execution ( new ( . . ) ) && excluded ( ) && included ( ) ;
Es werden also alle Joinpoints gematched, welche ein neues Objekt erzeugen. Nun muss
noch definiert werden was dann zu tun ist, dies geschieht im Advice. Hier benutzten wir
einen before() : InstancesCount() Advice. Als nächstes wird geprüft welches Objekt gerade
instanziert wurde. Dies geschieht mittels thisJoinPoint.getTarget().getClass().getCanonicalName();
- was uns die Packagestruktur sowie den Klassennamen liefert. Sollte
gerade eine lokale oder anonyme Instanz erzeugt worden sein – liefert die Methode Null.
Diese Ausnahme wird manuell behandelt und der Objektname dann auf ”
localOrAnonymous“
gesetzt.
27

Nun kann begonnen werden diese Logdaten in die Map zu schreiben. Zunächst wird geprüft,
ob zu dem Key – also hier dem Namen des instanzierten Objekts – bereits ein ValueObject
vorliegt. Falls dies nicht der Fall ist, wird ein neues angelegt und in die Map geschrieben.
Sollte bereits ein ValueObject zum jeweiligen Key vorliegen, wird dieses durch
seine Methoden um den Wert 1 inkrementiert. Hier also c.setCount(c.getCount()+1).
Nun sind die Daten in der Map gespeichert und somit die Aufgabe dieses Aspekts fertiggestellt.
28

5 Einbinden benutzerspezifischer
Aspekte in den Prototyp
Nachdem die Architektur und der allgemeine Ablauf des Programms vorgestellt worden
sind, wird in diesem Abschnitt ein detailliertes Beispiel für das Einbinden eines benutzerspezifischen
Aspekts im Programm beschrieben. Eine unaufwändige und schnelle
Erweiterung von Aspekten im Programm war eines der Hauptziele bei der Entwicklung
des Programms. Der Einbindevorgang wird anhand eines Beispielaspekts erläutert. Der
Beispielaspekt, der in diesen Kapitel vorgestellt wird, ist für die Zählung von Getterund
Setter-Methoden zuständig. Die nötigen Testklassen sowie die Aspektklasse befinden
sich im GetterSetter.jar auf der CD.
Bevor mit dem Erstellen des neuen Aspekts begonnen werden kann, ist es nötig, das
Projekt in Eclipse zu importieren. Zum Einbinden des Programms in Eclipse ist lediglich
die Installation von AJDT(AspectJ Development Tools) notwendig (siehe HowTo
Dokument). Im einzelnen muss zunächst ein neues Projekt erstellt werden, indem in
Eclipse das CLeverTec Programm importiert wird. Anschliessend muss das Projekt mit
Hilfe von AJDT in ein AspectJ Projekt konvertiert werden, falls dies nicht automatisch
geschehen ist. Das Projekt kann auch problemlos in Maven eingebunden werden, dazu
ist lediglich die Einbindung von JDOM-Bibliothek in der pom.xml notwendig.
Nun werden drei Testklassenn zu Testzwecken erstellt. Dazu muss zunächst ein neues
Package test.all.aspects im Verzeichnis src/test angelegt werden. Die Klasse Konto
enthält zwei Variablen guthaben und kontoNummer, zwei Methoden abheben(int Betrag)
und einzahlen(int betrag), sowie die für den neu einzubindenden Aspekt relevanten
Getter- und Setter-Methoden. Die Methode abheben() verursacht eine OverLimitException,
falls versucht wird, mehr Geld abzuheben als vorhanden ist. Die OverLimitException
Klasse ist eine selbstgeschriebene Exception, die von der Basisklasse Exception
abgeleitet ist. In der Mainmethode der Klasse TestKonto wird ein Konto erstellt und
eine Einzahlung sowie eine Abhebung wird ausgeführt, am Schluss wird dann die für relevante
getter-Methode getGuthaben() aufgerufen. Schließlich muss die Klasse Testkonto
als Java Application oder AspectJ/Java kompiliert und ausgeführt werden. Dabei wird
ein neues Verzeichnis out erstellt, die unter anderem eine XML-Datei out.xml enthält, in
der alle ausgewerteten Daten zusammengefasst sind. Um die Änderungen festzustellen,
die durch die Aspekterweiterung aufgetreten sind, sollte diese generierte XML Datei in
ein beliebiges Verzeichnis gespeichert werden. Der Aufbau und die Struktur der XML
Datei wird in Kapitel 5 näher erläutert.
29

Innerhalb des Projekts wird nun ein Package namens cleverTec.aspects.getterandsetter
und anschließend eine Klasse CountGetterAndSetter erstellt. Die Klasse CountGetterAndSetter
ist eine Implementierung des Interface ValueObject. Diese enthält zwei Methoden
zur Speicherung bzw. Ausgabe der entsprechenden Ergebnisse.
Dabei entspricht die Methode printValue() der Konsolenausgabe und die Methode toXM-
LElement() ist für das Festhalten der Daten in einer XML Datei verantwortlich. Des
Weiteren besitzt die Klasse zwei Variablen getSetNumber die für die Zählung der aufgerufenen
Getter- und Setter-Methoden zuständig ist und eine Variable getSet die die
Methodennamen der Getter- und Setter-Methoden speichert. Die Methode increment()
zählt die Anzahl der Getter- und Setter-Aufrufe um eins hoch.
30

Abbildung 5.1: ValueObject-Klasse CountGetterUndSetter
Innerhalb desselben Packages muss nun eine Aspektklasse GetterAndSetter erstellt werden,
die von AbstractAspect abgeleitet ist. In der GetterAndSetter Aspektklasse ist ein
pointcut definiert, der alle Getter und Setter-Methoden durchläuft. Nach jedem Aufruf
einer Getter- oder Setter-Methode, wird der Name der Methode sowie die aktualisierte
Anzahl der bisherigen Aufrufe mit Hilfe des Advice in eine HashMap gespeichert, die
ein Attribut der Aspektklasse ist.
31

Abbildung 5.2: Benutzerspezifisches Aspekt GetterAndSetter.aj
Nachdem nun erneut die Klasse TestKonto kompiliert und ausgeführt wurde, kann die
neu generierte XML mit der ursprünglichen XML Datei vor der Aspekterweiterung verglichen
werden. Innerhalb der neuen XML Datei ist ein weiterer Tag zu
finden, der in der alten XML Datei nicht vorhanden war.
Abbildung 5.3: Loggerausgabe mit dem Ergebnis des benutzerspezifischen Aspekts
Zusammenfassend sind folgende Punkte bei der Erstellung eigener Aspekte zu beach-
32

ten:
• Jeder neue Aspekt muss in einem eigenen Package erstellt werden (siehe Kapitel
4.3)
• Die Javaklasse implementiert das Interface ValueObject und damit dessen zwei
Methoden printValues() und toXMLElement(). Dabei gibt erstere die Daten auf
der Konsole aus und letztere speichert die Daten in geeignetem Format in die XML
Datei.
• Die Aspektklasse ist von der Klasse AbstracLogger abgeleitet. Von dieser erbt sie
das Attribut vom Typ Logger.
33

6 Benutzung des Prototyps
Die Idee der Anwendung war, dass man jeglichen Quellcode mit Aspekten versehen kann
und dadurch Messungen am Programm vornehmen kann. Dies kann auf zwei verschiedene
Arten erreicht werden. Zum einen kann man dies über Eclipse erreichen, zum anderen hat
man die Möglichkeit den Quellcode über einen Kommandozeilenaufruf mit den Aspekten
versehen zu lassen und kann das Kompilat daraus wie jedes andere Javaprogramm laufen
lassen. Als Ausgabe entsteht dadurch eine XML-Datei sowie eine CSV-Datei.
6.1 Was leistet das Programm?
Die Aspekte sind so gedacht, dass sie jedem beliebigem Quellcode hinzugefügt werden
können und den Quellcode so erweitern, dass statistische Informationen ausgelesen
werden können. In der vorliegenden Version können bereits folgende Daten ausgelesen
werden, sind also als Aspekt vorhanden:
• Instanzen zählen
• Methodenaufrufe zählen, sowohl gesamt wie zu jeder spezifisch
• Methodenlaufzeiten
• Threadinstanzen zählen
• Threadausführungen (Aufrufe von start())
• Exceptions die geworfen werden
Das Programm führt eine Statistik während der zu untersuchende Quellcode ausgeführt
wird und schreibt die erworbenen Daten, bei Beendigung der virtuellen Maschine, in eine
XML-Datei, welche zusätzlich noch gleich mit beliebigen XSLT-Templates transformiert
werden kann (z.B. CSV oder SVG-Ausgaben). Die Sammlung der Daten passiert somit in
Java nativem Code und kann daher auf jeder zur Javaspezifikation kompatiblen virtuellen
Maschine laufen, wenn es entsprechend ihrer Version kompiliert wurde.
6.2 Wie benutzt man das Programm?
Das Programm kann auf zwei verschiedene Arten benutzt werden. Zum einen durch einbinden
in ein Eclipseprojekt (6.3) und zum anderen durch Aufruf des Codeweavers (6.4),
34

welchem der zu untersuchende Quellcode und die Aspekte gegeben werden und dieser
dann die Aspekte an den Quellcode knüpft und ein lauffähiges Programm ausgibt.
6.3 Einbinden in ein Eclipseprojek
Der einfachste Weg ist den Quellcode, den Quellcode der Aspekte und dazugehöriger
Klassen in ein AspectJ-Projekt in Eclipse zu kopieren. Dann kann man die ganze Anwendung
direkt aus Eclipse heraus laufen lassen und muss sich um nichts weiter kümmern.
Das Anlegen eines AspectJ-Projekts funktioniert gleich wie das Anlegen eines normalen
Javaprojekts, nur das man eben als Projektbasis ein AspectJ-Projekt auswählt. Danach
ist zu empfehlen zwei Quellverzeichnisse anzulegen, eins für das Programm welches untersucht
werden soll und eins für die Aspekte. Jetzt wäre bereits alles lauffähig, aber
es können noch weitere Konfigurationen vorgenommen werden. In der Datei AbstractAspect.aj
können ausgeschlossene Bereiche, sowie explizit eingeschlossene Bereiche bestimmt
werden. Die hierbei relevanten Pointcuts sind folgende:
Listing 6.1: relevante Pointcuts bei der Verwendung des Prototyps
public pointcut excluded ( ) :
! within ( cleverTec . . ∗ ) ;
public pointcut included ( ) :
within ( ∗ ) ;
Alle Dateien oder Pakete die explizit ausgeschlossen werden sollen können in den Klammern
des ”
excluded“-Pointcut definiert werden. Die einzelnen Teilbereiche werden über
&& (logisches Und) oder ‖ (logisches Oder) verbunden. Wichtig hierbei ist, dass das
Paket des Prototypen sowie alle seine Unterpakete und Klassen (cleverTec..*) ausgeschlossen
werden. Als Beispiel für die Benutzung:
Listing 6.2: Benutzungsbeispiel des within() im Prototyp
! within ( cleverTec . . ∗ && java . s q l . . ∗
Diese Definition würde nun das Paket des Prototypen und dessen Unterpakete ausschließen
sowie zusätzlich alle Pakete von java.sql sowie dessen Unterpakete. Ähnlich läuft dies
nun mit den explizit zu inkludierenden Paketen und Dateien. Die Änderung die man hier
vornehmen muss, passiert in den Klammern des within-Fragments mit den gleichen Regeln
wie oben bei den für die explizit ausgeschlossenen Pakete. Die Grundeinstellung *
bedeutet, dass alle Pakete eingeschlossen werden (außer natürlich diejenigen die ausgeschlossen
sind). Das ist eigentlich auch schon alles was es zu konfigurieren gibt.
Man kann zusätzlich seine eigenen Aspekte schreiben aber sollte sie über den gerade
beschriebenen Mechanismus aus den Statistiken ausschließen.
35

Zuletzt bleibt nur noch zu konfigurieren wohin die Ausgabe geschrieben werden soll und
ob XSLT-Templates auf sie angewendet werden sollen - dies kann man mittels der Datei
clevertec.properties im Unterverzeichnis conf erledigen. Die Erklärung zu dieser Datei
ist im nächsten Abschnitt zu finden. Hat man nun dies alles gemacht kann man das zu
untersuchende Programm laufen lassen und am Ende des Laufs sind die gesammelten
Daten in den in der clevertec.properties definierten Ausgabedateien zu finden.
Das ganze wurde auch nochmal als Video beigelegt, in dem gezeigt wird wie man alles
in diesem Punkt beschriebene macht.
6.4 Einbinden über den Codeweaver
Der Codeweaver ist ein Javaprogramm, das einem letztlich den Aufruf für den acj
(AspectJ Compiler) von AspectJ abnimmt. Er baut den kompletten Aufruf auf, führt
ihn aus und fügt dem kompilierten Projekt noch Konfigurationsdateien hinzu. Was man
braucht um ihn zu benutzen sind die Aspect Tools von AspectJ, die unter anderem die
Laufzeitumgebung von AspectJ enthalten. Diese findet man hier:
http://www.eclipse.org/aspectj/downloads.php
Der Codeweaver selbst baut eigentlich nur eine Zeichenfolge auf mit welcher der ajc
von AspectJ aufgerufen wird, indem er einen Prozess dafür startet und die Zeichenfolge
ausführt. Die ganzen Daten, die benutzt werden um diesen Aufruf aufzubauen kommen
aus der config.properties-Datei. Das nachfolgende Bild sollte dies etwas deutlicher
machen.
36

Abbildung 6.1: Die Verwendung der config.properties-Datei
Anhand der Informationen aus dieser Datei wird dann ein mit den Aspekten versehener
Bytecode erzeugt, welchen man wie jedes andere Javaprogramm laufen lassen kann.
Zusätzlich werden noch die Verzeichnisse libs und conf, die im Arbeitsverzeichnis des
CodeWeavers liegen, kopiert. Zum Schluss wird noch eine Batch- oder Skriptdatei erzeugt,
je nach unterliegender Plattform, die dann mittels Parameterübergabe des Pfades
zur main-Methode den kompilierten Code ausführt.
Der Codeweaver kann sowohl unter Linux als auch unter Windows benutzt werden,
dabei ist natürlich zu beachten das die Pfadangaben für Dateien der jeweiligen Umgebung
angepasst werden müssen. Gehen wir nun Schritt für Schritt durch, wie man ihn
benutzt.
1. Als erstes brauchen wir eine Konfigurationsdatei mit dem Namen config.properties
im Arbeitsverzeichnis. Da man diese wahrscheinlich noch nicht hat kann man sie
mittels dem Aufruf ”
java cleverTec.ajc.Codeweaver -makeconfig“ erzeugen lassen.
Der Aufbau der Konfigurationsdatei wird am Ende des Abschnittes erklärt
2. Nachdem man die Konfigurationen gesetzt hat, u.a. wo die AspectJ-Bibliotheken
sowie der zu untersuchende Quellcode liegt, kann man dann den Codeweaver aufrufen
mittels: java cleverTec.ajc.Codeweaver. Dieser generiert einem dann den By-
37

tecode verwoben mit den Aspekten und zusätzlich, in dem in der Konfigurationsdatei
definiertem Ausgabeverzeichnis, ein Unterverzeichnis mit dem Namen conf,
in welchem eine Konfigurationsdatei namens clevertec.properties für das gerade
kompilierte Programm liegt.
3. Danach können wir in das Ausgabeverzeichnis wechseln und noch Einstellungen in
der Konfigurationsdatei clevertec.properties vornehmen:
xmloutfile definiert den Namen der xml-Ausgabedatei
xsltfiles p10cm definiert die Namen der Umwandlungsdateien, die die xml-
Ausgabe weitertransformieren. Durch ;“ getrennt – Reihenfolge
”
analog zu xsltouts
xsltouts definiert die Namen der zusätzlichen Ausgabedateien, die mittels
XSLT-Files generiert werden. Durch ;“ getrennt – Reihenfolge analog
zu ”
xsltfiles.
4. Im letzten Schritt muss man nur noch die main-Methode des kompilierten Programms
aufrufen und nach Beendigung ist sowohl die xml- als auch die csv-Ausgabe
vorhanden in den jeweils im clevertec.properties definierten Dateien.
Das war eigentlich schon alles was man machen muss. Es fehlt nur noch die Konfiguration
des Codeweaver über dessen Konfigurationsdatei config.properties in dessen Arbeitsverzeichnis.
Hier ein Beispiel für eine Windowskonfiguration und danach die Erklärungen
der einzelnen Variablen:
Listing 6.3: Die Konfigurationsdatei config.properties
FURTHERJAVAARGS=
ACJCLASSPATH=Libs \\jdom −1.1\\jdom . j a r ;
C:\\ Programme\\ Java \\ a s p e c t j \\ l i b \\ a s p e c t j r t . j a r
DESTINATION=t e s t B i n
FURTHERACJARGS=−source 1 . 5
ASPECT LIB PATH=C:\\ Programme\\ Java \\ a s p e c t j \\ l i b
JAVAFILES=t e s t s S o u r c e s \\ t e s t S o u r c e s \\ threads \\;\
s r c \\ cleverTec \\ l o g g e r \\;\
s r c \\ cleverTec \\ a s p e c t s \\methodExecutionNumber \\;\
s r c \\ cleverTec \\ a s p e c t s \\ threads \\;\
s r c \\ cleverTec \\ u t i l \\
ACJ=org . a s p e c t j . t o o l s . a j c . Main
CLASSFILESGIVEN=0
Die Konfigurationsdatei ist eine Java konforme properties-Datei. Deswegen auch die ”
\\“
in den Windowspfadangaben. Ansonsten gelten die üblichen Regeln für solche Dateien.
Die Erklärung der einzelnen Variablen:
38

FURTHERJAVAARGS
ACJCLASSPATH
DESTINATION
FURTHERACJARGS
ASPECT LIB PATH
JAVAFILES
ACJ
CLASSFILESGIVEN
Hier können zusätzliche Argumente für den Javakompilierer
(javac) übergeben werden, z.B. -Xstdout
Hier müssen die vom acj zur Übersetzung benötigten Bibliotheken
übergeben werden. Mehrere Angaben sollten mittels
Strichpunkt getrennt werden
Diese Variable bestimmt das Ausgabeverzeichnis wo die kompilierten
Dateien hingeschrieben werden sollen
Dies sind Argumente die dem acj zusätzlich übergeben werden
sollen, ähnlich wie FURTHERJAVAARGS
Hier müssen die AspectJ-Bibliotheken angegeben werden die
u.a. den acj enthalten der zum übersetzen der Javadateien
benutzt werden soll
Hier werden sowohl der zu untersuchende Quellcode angegeben
als auch die Aspekte die man benutzen möchte. Wenn die
Angaben mit einem systemspezifischen Pfadseparator, z.B.
Unix /“, enden, werden die verschiedenen Pfade passend umgebaut
und als Argument an den acj übergeben. Falls sie nicht
”
so enden werden dem acj nur die angegebenen Dateien, welche
mit .java oder .aj enden sollten, übergeben. Wenn man mehrere
Pfade angeben will kann man diese mittels Strichpunkt
trennen.
Der eigentliche Aufruf des acj selbst. Falls sich irgendwann
einmal die Struktur der AspectJ-Bibliotheken ändert kann das
hier angepasst werden
Entweder 0 oder 1. Bei 0 bedeutet dies, dass man nur Quellcode
kompilieren will (.java), bei 1, dass man nur kompilierte
Dateien verweben will (.class-Dateien)
6.5 Ausführen mittels Ant-Task
AspectJ liefert standardmäßig Taskdefinitions für das weitverbreitete Build-Tool Ant
(siehe [The]) mit jedem Release in der ”
aspectjtools.jar“ aus. Damit ist die Integration
des AspektJ-Compilers ”
ajc“ in Ant ein leichtes. Ein sehr einfaches compile Target für
Ant könnte in etwa so aussehen:
Listing 6.4: Ein einfaches compile Target für Ant
39

Der Aufruf kompiliert hier sämtliche .java und .aj Dateien im Verzeichnis src
und testsSrouces und schreibt die kompilierten .class Dateien in das destDir-Verzeichnis
– ajc agiert hier also ebenso wie javac, nur eben mit AspectJ Unterstützung. Je nachdem
welches Projekt hier kompiliert werden soll, müssen weitere Bibliotheken im Classpath
angegeben werden, oder Konfigurationsdateien mit in das destDir kopiert werden.
Hierfür kann die Build-Datei beliebig erweitert werden. Für einfache Aufgaben sind hier
kaum Kentnisse der Ant-Syntax notwendig, die Build-Datei ist ausserdem für sich sehr
sprechend.
Um das volle potential des AspektJ-Compilers auszunutzen und sich so die Möglichkeit
zu erschließen inkrementell zu kompilieren oder ByteCode-Weaving, also das anwenden
eines Aspekts auf bereits kompilierte .class Dateien (bzw. .jar-Dateien), zu betreiben –
verweisen wir auf die sehr gute Dokumentation der AspectJ-Ant-Tasks unter [Aspa].
Das aktuell enthaltene Buildfile aspectj build.xml kompiliert sämtliche Aspekte und
Tests. Um es zu verwenden sind folgende Schritte vorzunehmen:
Zunächst sollte Ant in einer möglichst neuen Version installiert werden und das ant/bin-
Verzeichnis gegebenenfalls zur Path-Variable hinzugefügt werden, um Ant direkt als
Kommando in der Konsole verwenden zu können. Nun müssen noch die Properties im
aspectj build.xml angepasst werden. Besonders wichtig sind hier die beiden Properties
Diese müssen auf den jeweiligen Pfad zeigen, in dem AspectJ installiert wurde.
Um unsere Beispiele auszuführen ist sonst keine weitere Einstellung nötig. Sollen aber
andere Projekte kompiliert werden, muss das classpath compile bzw. classpath execution
Property gegebenenfalls um weitere librarys erweitert werden.
Nun kann das default-target, hier compile, per Kommandozeile gestartet werden: ”
ant
–f aspectj build.xml“ führt das default-target aus. Zunächst, wird falls vorhanden der
Ordner ant-out im relativen Verzeichnis gelöscht (clean). Dann werden Librarys und
Konfigurationsdateien ins ant-out Verzeichnis kopiert(copy). Zu guter letzt werden noch
sämtliche java/aj Dateien compiliert, sowie alle weiteren Dateien die sich in den beiden
sourceroot-Verzeichnissen befinden ins jeweilige ant-out Unterverzeichnis kopiert
(ausgeschlossen von diesem Kopieren sind .java und .aj Dateien – siehe SourceRootCopyFilter).
Nun können die kompilierten .class Dateien ganz normal per java Aufruf ausgeführt werden
(zusätzlich muss man nur die aspectjrt.jar im Classpath angeben) – auch dies kann
40

per Ant erledigt werden. ant –f aspectj build.xml run“ startet z.B. die Main-Methode
”
der Klasse testSources.threads.Restaurant – dies kann durch setzen des mainclass-properties
in der XML-Datei auch geändert werden, oder per Kommandozeile direkt überschrieben
werden:
ant –f aspectj build.xml run -Dmainclass=testSources.svg.SVG Coordinate System Test“
”
führt also die Klasse testScources.svg.SVG Coordinate System Test aus.
Ant bietet noch viele weitere Möglichkeiten automatische Builds und weitere Aufgaben
zu realsieren. Hierfür verweisen wir auf die Ant-Dokumentation unter [Apa].
Durch die Verwendung des Ant-Build-Files ist eine nahtlose Integration in eventuell bereits
bestehende automatische Buildprozesse möglich. So könnten beispielsweise Tests
mithilfe von AspectJ geschrieben werden und die von uns dabei erzeugten Ausgaben direkt
ausgewertet, oder die SVG-Grafiken in Report-Seiten miteingebunden werden. Hier
ist auch zu beachten, dass weitere XSL-Transformationen direkt per clevertec.properties
eingebunden werden können. So könnte aus den Ergebnissen direkt eine passende XHTML-
Seite generiert werden, welche dann automatisch generiert wird und weiterverarbeitet
werden kann (Maven, CruiseControl, Wikis etc..).
6.6 Was wird Ausgegeben?
Hat man nun den einen oder anderen Weg genommen um sein Programm mit den
Aspekten zu verweben und laufen zu lassen bekommt man als Ergebnis sowohl eine
XML-Datei, sowie eventuell weitere durch XSLT erzeugte Dateien. Die XML-Datei ist
so aufgeteilt, dass zu jedem Unterpaket von clevertec.aspects eine Sektion aufgemacht
wird und die Werte die über die dort enthaltenen Aspekte gesammelt wurden in diese
Sektion geschrieben werden. Die einzelnen Aspekte in jedem Paket wiederum bekommen
eine eigene Sektion mit dem Namen ëntry”welcher den Aspekt definiert. In dieser
ëntrySektion sind dann die Werte die von dem jeweiligen Aspekt gesammelt wurden,
als Kindelemente mit Attributen enthalten. Die Formatdefinition dieser Kindelemente,
also welcher Wert ist ein Attribut oder sollen Werte als Elemente eingefügt werden, wird
von dem zum Aspekt gehörigen ValueObject bestimmt. Präziser, die Methode toXM-
LElement (implementiert von dem Interface ValueObject) bestimmt wie die Ausgabe
innerhalb jedes ëntryäussieht.
Die CSV-Datei wird eigentlich in mehreren Teilen ausgegeben (momentan). Die Idee
hierbei ist, dass die CSV-Datei(en) mit Hilfe von XSLT-Datei(en) aus der produzierten
XML-Datei erzeugt wird. Die XSLT-Datei(en) die benutzt werden soll, wird einfach
in der clevertec.properties unter xsltfiles vermerkt (siehe 6.4 ). Diese Dateien werden
dann zusätzlich nach Beendigung der XML-Ausgabe verarbeitet. Über diesen Mechanismus
kann man leicht beliebige CSV-Ausgaben erzeugen, die immer an die Umstände
angepasst werden können sowohl mit den Daten als auch mit dem Format.
41

Literaturverzeichnis
[Apa]
Apache Ant 1.7.0 Manual. http://ant.apache.org/manual/index.html, Abruf:
20. Januar 2008
[Aspa] AspectJ Ant Tasks. http://www.eclipse.org/aspectj/doc/released/
devguide/antTasks.html, Abruf: 20. Januar 2008
[Aspb] The AspectJ Programming Guide. http://www.eclipse.org/aspectj/doc/
released/progguide/index.html, Abruf: 20. Januar 2008
[Böh06] Böhm, Oliver: Aspekorientierte Programmierung mit AspectJ 5. Dpunkt-
Verlag, 2006. – ISBN 3–89864–330–1
[Lad03] Laddad, Ramnivas: AspectJ In Action. Manning, 2003. – ISBN 1–930110–93–6
[Mar] Metric mishap caused loss of NASA orbiter. http://www.cnn.com/TECH/
space/9909/30/mars.metric.02/, Abruf: 20. Januar 2008
[Syn] Syntax der TypePatterns. http://www.eclipse.org/aspectj/doc/
released/progguide/semantics-pointcuts.html#type-patterns, Abruf:
20. Januar 2008
[The] The Apache Ant Project. http://ant.apache.org/, Abruf: 20. Januar 2008
42

Abbildungsverzeichnis
1.1 Logging in Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 XML-Parsing in Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Wo AOP angreift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Eine Java-Klasse Konto mit Beispiel-Join-Points . . . . . . . . . . . . . . 9
2.3 Der Advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Blackbox-Ansicht eines Projekts . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Umwandlung eines Java-Projekts in ein AspectJ-Project . . . . . . . . . 16
3.3 Der Aspekt Ausgeben von SQL-Statements zeigt auf eine Codestelle . . . 18
3.4 Main-Methode, auf die der Aspekt Ausgeben von SQL-Statements zeigt . 18
4.1 Die excluded-/included-Anweisung . . . . . . . . . . . . . . . . . . . . . 22
4.2 Die technische Architektur des Prototyps . . . . . . . . . . . . . . . . . . 23
4.3 Programmablauf des Prototypen . . . . . . . . . . . . . . . . . . . . . . . 26
5.1 ValueObject-Klasse CountGetterUndSetter . . . . . . . . . . . . . . . . . 31
5.2 Benutzerspezifisches Aspekt GetterAndSetter.aj . . . . . . . . . . . . . . 32
5.3 Loggerausgabe mit dem Ergebnis des benutzerspezifischen Aspekts . . . . 32
6.1 Die Verwendung der config.properties-Datei . . . . . . . . . . . . . . . . 37
43

Listings
2.1 Ein Aspekt in AspectJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Die erste Codezeile vom Aspekt SqlStatementsAspect . . . . . . . . . . . 17
3.2 Pointcut- und Join-Point-Definition im Aspekt SqlStatementsAspect . . . 17
3.3 Advice-Definition im Aspekt SqlStatementsAspect . . . . . . . . . . . . . 17
6.1 relevante Pointcuts bei der Verwendung des Prototyps . . . . . . . . . . . 35
6.2 Benutzungsbeispiel des within() im Prototyp . . . . . . . . . . . . . . . . 35
6.3 Die Konfigurationsdatei config.properties . . . . . . . . . . . . . . . . . . 38
6.4 Ein einfaches compile Target für Ant . . . . . . . . . . . . . . . . . . . . 39
44