Java für Fortgeschrittene Proseminar im Sommersemester 2009 Von Objektorientierung zu Aspektorientierung: AspectJ

Transkript

1 Java für Fortgeschrittene Proseminar im Sommersemester 2009 Von Objektorientierung zu Aspektorientierung: AspectJ Julia Strauß Technische Universität München Zusammenfassung Diese Arbeit gibt einen Einblick in die aspektorientierte Programmierung am Beispiel von AspectJ und zeigt den Nutzen der Verknüpfung von aspektorientierter Programmierung und objektorientierter Programmierung, um Anforderungen zu realisieren, welche nicht nur einzelne Module sondern ein gesamtes Softwareprojekt betreffen. 1 Einleitung Durch die Feststellung, dass eigenständige Anforderungen wie z.b. Sicherheitsaspekte an ein Anwendungs-Projekt nur schlecht in Bezug auf Wartbarkeit, Wiederverwendbarkeit und Verständlichlichkeit von bestehenden Programmiermethodiken abgedeckt werden, wurde das Konzept der aspektorientierten Programmierung entwickelt. Bekannterweise werden in der objektorientierten Programmierung einzelne Objekte der realen Welt in Form von Klassen modelliert. Oftmals sind diese einzelnen Klassenmodule jedoch z.b. von sicherheitsrelevanten Anliegen, Transaktionsverwaltung oder Auditfähigkeit durchsetzt, welche für alle oder einen großen Anteil der Module gelten. In der objektorientierten Programmierung ist das sinnvolle Einweben solcher querschneidenden Anforderungen nur schwer bis gar nicht möglich, da diese über den gesamten Code verstreut sind. In dieser Situation ermöglicht der Einsatz der aspektorientierten Programmierung diese Problematik erfolgreich zu bewältigen, da in diesem Modell einzelne Aspekte gekapselt werden, welche dann mit dem restlichen Code verwoben werden können. Ein Anwendungsbeispiel wäre die Überprüfung, ob ein Benutzer die passende Legitimation hat, um bestimmte Methoden auszuführen. Hier kann die aspektorientierte Programmierung modulübergreifend eine Berechtigungskontrolle 1

2 einführen, ohne dass die einzelnen Methoden dies selbst überprüfen müssen. In dieser Ausarbeitung werden wir zunächst näher darauf eingehen, was man überhaupt unter Aspektorientierung versteht. Im Anschluss beschäftigen wir uns genauer mit AspectJ, das Aspektorientierung für Java umsetzt. Daraufhin werden wir uns mit den verschiedenen Anwendungsgebieten und den Vor- und Nachteilen aspektorientierter Programmierung auseinander setzen. 2 Aspektorientierte Programmierung 2.1 Begriffsklärung und Anwendungsgebiete Beschäftigt man sich mit größeren Softwareprojekten, so fällt oft auf, dass gewisse Anforderungen wie Security, Tracing oder Programmierrichtlinien den gesamten Code durchziehen. Möchte man z.b. in einer Anwendung alle Aufrufe von bestimmten Methoden protokollieren, so muss bei der objektorientierten Programmierung jede Methode an einen Logger melden, dass sie ausgeführt wird. Diese Meldung ist für die eigentliche Funktionalität der Methode unwichtig und die einzelnen Methoden, welche geloggt werden, sind meist sehr verstreut über die gesamte Anwendung. Betrachtet man diese Punkte, so wird deutlich, dass dies die Wartbarkeit, Wiederverwendbarkeit und Verständlichkeit eines Systems stark beeinträchtigt. Abhilfe schafft hier die aspektorientierte Programmierung. Bei ihr werden verschiedene logische Aspekte getrennt von den Modulen entworfen und im Nachhinein mit dem Gesamtprojekt verbunden. Unter Aspekten verstehen wir dabei alle eigenständigen Anforderungen, die sich nicht einem einzelnen Modul zuordnen lassen. Ermöglicht wird dies, indem die objektorientierte Sprache um syntaktische Elemente erweitert wird, die diese Aspekte modulübergreifend definiert. Hierbei enthält der Aspekt eine Liste wohldefinierter Punkte und den an diesen Punkten auszuführenden Code. Beim gerade erwähnten Tracing-Beispiel kann das Logging von einem Aspekt übernommen werden, der alle gewünschten Methoden einbezieht. Die Methoden müssen hierbei die Aspekte nicht kennen und können ohne Probleme modifiziert werden. 2

3 Damit sind die einzelnen Aspekte von den restlichen Modulen getrennt, was die Wartbarkeit dank verbesserter Verständlichkeit, Wiederverwendbarkeit und erleichterter Nachvollziehbarkeit massiv erhöht. AOP bietet demzufolge eine elegante Lösung, um Aspekte vom restlichen System losgelöst zu betrachten. 2.2 Arten des Webens In der Praxis lassen sich verschiedene Verfahrensweisen finden, um das Zusammenspiel zwischen Aspekten und den zugehörigen Modulen zu realisieren. Das Weben bezeichnet hierbei den Prozess, wenn der Aspektcode mit dem Kernprogramm verknüpft wird. Eine mögliche Strategie ist es, den vorhandenen Aspektcode vor dem eigentlichen Kompilierungsvorgang in eine traditionelle Programmiersprache umzuwandeln, so dass er dann mit einem herkömmlichen Compiler übersetzt werden kann. In den frühen Entwicklungsphasen von AspectJ wurde diese Strategie, welche auch Source-Weaving genannt wird, genutzt, um den Aspektcode mit den betreffenden Klassen zu verknüpfen. Inzwischen nutzt AspectJ unter anderem Compile-Time-Weaving. Hierbei wird der vorhandene Quellcode während des Kompilierungsvorgangs mit dem Aspektcode verwoben. Dabei kann der Aspektcode selbst auch als Bytecode auftreten. Dieses Vorgehen ist notwendig, wenn die Aspekte beispielsweise At- 3

4 tribute zu den bestehenden Klassen hinzufügen und andere Klassen auf diese Attribute zugreifen. Beim Post-Compile-Weaving werden die Aspekte nach dem Kompilierungsvorgang mit den Klassen verwoben. Da hierbei die Klassen in Bytecode vorliegen, wird dieses Verfahren auch Bytecode-Weaving genannt. Das dritte Verfahren, welches ebenfalls von AspectJ genutzt wird, ist das Verweben der Aspekte in den Bytecode unmittelbar bevor die betreffende Klasse durch den Classloader geladen wird. Hierbei werden jedoch zusätzlich WeavingClassLoader benötigt, um den Vorgang realisieren zu können. 3 AspectJ Im November 2001 veröffentlichte Xerox Palo Alto Research Center nach langjähriger Entwicklungsarbeit die Aspektsprache AspectJ[4] für die Java Umgebung. Der sprachliche Aufbau der Aspekte stellt eine Kombination von herkömmlichem Javacode und AspectJ da. Die einzelnen Sprachkonstrukte sind Joinpoints (Punkte, an denen AspectJ Code einfügt werden kann), Pointcuts (ein Konstrukt, um diese Punkte sprachlich zu beschreiben) und Advice (Code, der an den Pointcuts ausgeführt werden kann). Des Weiteren bietet AspectJ die Möglichkeit, in die Struktur der Programme durch Inter-Type-Declarations einzugreifen. 4

5 AspectJ wurde später an die Eclipse Foundation weitergegeben und wird seitdem dort weiterentwickelt. Unter anderem wurden die Möglichkeiten AspectJ mit herkömmlichem Javacode zu verbinden, erweitert und seit Version 1.5 eine Unterstützung von Generics und Annotations hinzugefügt. Nach dem Webvorgang von Aspekten und Klassen entsteht hierbei vollständig kompatibler Bytecode, welcher auf jeder JVM ausgeführt werden kann. Durch seine hohe Funktionalität konnte sich AspectJ bisher gegen andere Frameworks wie Spring[7] durchsetzen, da dieses zwar weniger kompliziert ist, jedoch auch geringere Einflussmöglichkeiten bietet. 3.1 Joinpoint Unter Joinpoints versteht man Verknüpfungspunkte in einem Programm bei denen in die momentane Ausführung eingegriffen werden kann. Typische Verknüpfungspunkte wären z.b. Methodenaufrufe, Ausnahmebehandlungen, Initialisierung von Klassen und Objekten, Feldzuweisungen und -abfragen und weitere Punkten im Programmablauf. In diesem beispielhaften Programmcode eines Loggers kann man sehen, an welchen Punkten im Programm Joinpoints auftreten. Code vom Java Programm: package l o g g i n g ; public class Auto { int ps ; public Auto ( int ps ){ this. ps=ps ; public void printps ( ) { System. out. p r i n t l n ( ps ) ; public s t a t i c void main ( S t r i n g [ ] args ){ Auto a = new Auto ( 9 0 ) ; a. printps ( ) ; Code vom Aspekt : package l o g g i n g ; public aspect Logging { before ( ) : within ( Auto ){ System. out. p r i n t l n ( t h i s J o i n P o i n t S t a t i c P a r t ) ; 5

6 Ausgabe der Joinpoints: staticinitialization(logging.auto.<clinit>) execution(void logging.auto.main(string[])) call(logging.auto(int)) preinitialization(logging.auto(int)) initialization(logging.auto(int)) execution(logging.auto(int)) set(int logging.auto.ps) call(void logging.auto.printps()) execution(void logging.auto.printps()) get(printstream java.lang.system.out) get(int logging.auto.ps) call(void java.io.printstream.println(int)) Wie in der Ausgabe der Joinpoints sichtbar, wird zuerst die Ausgangsklasse statisch intialisiert und als nächstes die main() -Methode ausgeführt. Dann wird der Konstruktor von Auto aufgerufen und ein neues Objekt vom Typ Auto initialisiert, dabei wird der Konstruktor des Objektes ausgeführt und es erfolgt ein schreibender Zugriff auf die Variable ps. Im nächsten Schritt wird die Methode printps() aufgerufen und ausgeführt. Im Anschluss wird die Variable ps mit Hilfe des PrintStreams auf der Konsole ausgegeben. Bei all diesen auftretenen Joinpoints kann mit AspectJ eingriffen werden. Schleifen, Aufrufe von super, Throw Klauseln und Multiple Statements sind keine Verknüpfungspunkte, bei denen Joinpoints vorhanden sind. Somit können diese nicht mit Hilfe von AspectJ modifiziert werden Pointcut Pointcuts, auch Schnittpunkte genannt, werden genutzt, um verschiedene Joinpoints auszuwählen und zusammenzufassen. Zunächst kommen wir zur allgemeinen Syntax eines Pointcuts. Dieser hat die folgende Form: pointcut <name> (<parameter>): <ausdruck>; Der Name ist hierbei frei wählbar. Beispielsweise wäre ein akzeptierter Pointcut: pointcut t e s t ( ) : set ( S t r i n g Stock. f i l e n a m e ) ; Bei diesem Pointcut werden alle Joinpoints ausgewählt, die einen schreibenden Zugriff auf die Variable filename in der Klasse Stock betrachten. Es gibt eine Reihe von verschiedenen Ausdrücken, die genutzt werden können, um die verschiedenen Joinpoints auszuwählen. Dazu gehören unter anderem: call(<signatur>) : Der Pointcut reagiert auf das Aufrufen einer Methode, welche die angegebene Signatur trägt. Die Signatur kann zusätzlich auch reguläre Ausdrücke beinhalten. 6

7 set(<signatur>) get(<signatur>): Diese Pointcuts reagieren auf Zugriffe auf Variablen. Hierbei wird zwischen lesenden (get()) und schreibenden(set()) Zugriffen unterschieden. execution(<signatur>): Wenn eine beliebige Methode ausgeführt wird, die der angegebenen Signatur entspricht, so wird der betreffende Joinpoint mit Hilfe dieses Ausdruckes ausgewählt. Der Joinpoint ist hierbei schon im Kontext der Methode. adviceexecution(): Prinzipiell ähnlich zu execution, betrifft jedoch jegliche Ausführung von Advices. handler(<typepattern>): Unter Verwendung dieses Ausdruckes werden die Verknüpfungspunkte im Programm ausgewählt, welche die Ausführung einer Ausnahmebehandlung passend zum angegebenen TypePattern betreffen. this(<typ oder ID>): Überprüft, ob die dem aktuell ausgeführten Code zugehörige Objektinstanz vom angegebenen Typ ist. target(<typ oder ID>): Überprüft, ob das Zielobjekt vom angegebenen Typ ist. args(<typ oder ID,...>): Jeder Joinpoint, in dem die Methodenparameter vom angegebenen Typ sind. within(<typepattern>): Jeder Joinpoint im Code, welcher von einem Typ aus TypePattern (wie z.b. Object, java.util.hashmap, Stock, etc.) definiert wird. withincode(<signatur>): Jeder Joinpoint im Code in einer Methode oder im Konstruktor, der der angegebenen Signatur entspricht. initialization(<signatur>): Jegliche Initialisierung eines Objektes bei dem der Konstruktor der angegebenen Signatur entspricht. Für Interessierte lassen sich weitere Ausdrücke im Programming Guide von AspectJ[11] finden. Des Weiteren ist es möglich, mit Hilfe von logischen Operatoren wie and, or oder not komplexe Konstrukte anzugeben, die die getroffene Auswahl bestimmen. pointcut choose ( ) : c a l l ( void Habit. seth ( int ) ) c a l l ( void Habit. sett ( int ) ) ; In diesem Beispiel werden alle Joinpoints, welche entweder Aufrufe der Methode seth und sett aus der Klasse Habit beschreiben, ausgewählt. Zusätzlich ist es auch möglich mit Hilfe von Wildcards zu arbeiten. Dies ist äußerst nützlich, um mehrere Methoden aus verschiedenen oder auch der gleichen Klasse auszuwählen. * steht hierbei für beliebige Sequenz von Zeichen außer dem Punkt und.. für eine beliebige Sequenz von Zeichen inklusive des Punktes. 7

8 pointcut choose ( ) : c a l l (. s e t ( int ) ) ; Hier werden alle Joinpoints ausgewählt, deren Methodenname mit set beginnt und denen als Parameter eine Int Variable übergeben wird. Somit ist es auch möglich, Methoden, Felder oder unter anderem Konstruktoren aus verschiedenen Klassen (oder sogar aus Interfaces) zu selektieren, um somit die gewünschten querschneidenden Anforderungen zu realisieren Advice Advices dienen zur Bestimmung des auszuführenden Code bei einem oder mehreren Joinpoints. Sie werden mit folgender Syntax genutzt: <advicespez> [throws TypeList] : <pointcut> {<body> Der Rumpf eines Advices hat den gleichen Aufbau wie die bereits bekannten Methodenrümpfe aus Java. Es gibt verschiedene Arten von Advices, welche an Stelle von <advicespez> eingesetzt werden können. Dies sind entweder around(<parameter>), before(<parameter>) oder after(<parameter>). before(<parameter>): Bei before wird der Advice ausgeführt, sobald die angegebenen Joinpoints erreicht werden, aber bevor deren Bearbeitung begonnen wird. Bei einem Methodenaufruf passiert dies, nachdem das Argument zum Methodenaufruf ausgewertet wurde. before ( ) : c a l l ( Stock. (.. ) ) { System. out. p r i n t l n ( Something w i l l be c a l l e d i n Stock. ) ; In diesem Beispiel wird vor dem Aufruf der Methode auf der Konsole der String Something will be called in Stock. ausgegeben. after(<parameter>)[returning throwing (<parameter>)]: Dieser Advice wird ausgeführt, nachdem der Joinpoint ausgeführt wurde. Hierbei kann unterschieden werden, ob der Joinpoint erfolgreich beendet wird oder eine Ausnahme wirft. Diese Unterscheidung wird mit Hilfe von returning und throwing gewährleistet. Ohne diese Angaben wird der Advice in beiden Fällen ausgeführt. Bei einem Methodenaufruf würde der Advice betreten, nachdem die Bearbeitung des Methodenrumpfs abgeschlossen ist. a f t e r ( S t r i n g s ) : set ( S t r i n g Stock. f i l e n a m e)&& args ( s ){ System. out. p r i n t l n ( f i l e n a m e was changed to +s+. ) ; Hier wird nach einem schreibenden Zugriff auf das String-Attribut filename der neue Wert ausgegeben. 8

9 around(<parameter>): Die Bearbeitung des around()-advice fängt an, wenn der JoinPoint erreicht wird. Sie wird anstatt des eigentlichen Joinpoints ausgeführt und kann mit Hilfe von proceed(..) über dessen Abfertigung entscheiden. Hierbei hat der Aufruf von proceed() die gleichen Parameter wie der around()-advice. Des Weiteren kann around() auch über den Rückgabewert des Joinpoints bestimmen. Da around() anstatt eines Joinpoints ausgeführt werden kann, muss für diesen Advice auch ein Rückgabewert deklariert werden. i n t around( int x, int y ) : c a l l ( add ( int, int))&& args ( x, y ) ; int t = proceed ( x 2, y 2 ) ; return t / 2 ; An diesem Beispiel sehen wir, dass unser Advice bei allen Methodenaufrufen von add mit zwei Übergabeparametern vom Typ int ausgeführt wird. Hierbei werden mit Hilfe von args die Übergabeparameter von add für den Advice zugänglich gemacht. Nachfolgend werden die Variablen verdoppelt und dem ursprünglichen Joinpoint übergeben. Das vom Joinpoint berechnete Ergebnis wird halbiert und anschließend zurückgegeben. Die bisherigen Beispiele für Advices nutzten alle anonyme Pointcuts. Mit anderen Worten Pointcuts, denen wir bisher keinen konkreten Namen zugeordnet haben. In Kapitel Pointcuts haben wir kennengelernt, wie man einen Pointcut definiert. pointcut choose ( Habit t, int x ) : c a l l ( void Habit. s e t ( int ) ) && target ( t ) && args ( x ) ; after ( Habit t, int x ) : choose ( t, x ) ; System. out. p r i n t l n ( A value i n +t+ i s s e t to +x ) ; Hier werden bei allen Aufrufen von Methoden, deren Name mit set beginnt, und deren Übergabeparameter vom Typ int ist, das jeweilige Zielobjekt und der durch die set-methode neu zugewiesene Wert ausgegeben. Man kann Pointcuts genauso wie Joinpoints durch reguläre Ausdrücke verbinden. Man kann unter Nutzung von after() auch auf den Rückgabewert oder die geworfene Ausnahme eines Joinpoints zugreifen. after ( ) returning ( long a ) : c a l l ( int (.. ) ) { System. out. p r i n t l n ( Result : +a ) ; In diesem Fall muss beachtet werden, dass der Rückgabewert des Joinpoints ein Subtype vom Rückgabewert von returning ist. Oder im Fall von Primitives, dass der Rückgabewert vom Joinpoint den gleichen oder einen kleineren Wertebereich hat. 9

10 after ( ) throwing ( Exception e ) : c a l l ( void ( ) ) { System. out. p r i n t l n ( e ) ; Hier wird die geworfene Ausnahme ausgegeben. Es ist zu beachten, dass, wenn die Kontrolle an den Joinpoint zurückgegeben wird, die Ausnahme erneut geworfen wird. Da es möglich ist, verschiedene Advices zu den gleichen Pointcuts zu erstellen, stellt sich die Frage, welcher Advice bei der Ausführung den Vorrang hat. Hierbei sind unterschiedliche Fälle zu betrachten. Im nächsten Kapitel werden wir den Befehl declare precedence kennen lernen. Mit diesem Befehl kann man angeben, dass ein Aspekt A Vorrang vor einem anderen Aspekt B hat und somit auch alle Advices von A vor den Advices von B ausgeführt werden. Des Weiteren haben Untertypen eines Aspektes immer Vorrang vor deren Obertyp. Stehen zwei Aspekte in keinerlei Verbindung, so ist der Vorrang undefiniert und es kann zu nicht deterministischem Verhalten kommen. Innerhalb eines Aspektes müssen ebenfalls zwei Fälle unterschieden werden. Um zu entscheiden, welcher von zwei Advices Vorrang hat, wird zunächst überprüft, ob einer von beiden ein Advice vom Typ after() ist. Ist dies der Fall, so wird der Advice ausgeführt, der als letztes im Programmcode steht. Ist dies nicht der Fall, wird immer der Advice als erstes ausgeführt, der zuerst im Programmcode steht. Durch diese Definition des Vorrangs zwischen Advices können aber auch unerwünschte Zirkulationen im Aspekt entstehen. Dies kann jedoch auch genutzt werden, um zu gewährleisten, dass zwei Aspekte voneinander vollkommen unabhängig sind, indem wir ihnen gegenseitig Vorrang vor den jeweilig anderen geben. Dazu mehr im Kapitel Inter-Type-Declaration. Allgemein sollte man bedenken, dass es zwar viele Vorteile bringt, wenn man Wildcards wie * und.. nutzt, aber dass dies auch zu Endlosschleifen führen kann. aspect A{ before ( ) : c a l l ( (.. ) ) { System. out. p r i n t l n ( b e f o r e ) ; after ( ) : c a l l ( (.. ) ) { System. out. p r i n t l n ( a f t e r ) ; In diesem Fall reagiert unser Joinpoint call auf das println im eigenen Rumpf. Dadurch wird der Advice immer wieder aufgerufen. Wir gelangen in eine Endlosschleife. Vermeidbar ist dies, indem wir unseren Poincut um!within(a) erweitern. Es ist also durchaus möglich, dass ein uneingeschränkter Pointcut weit mehr auswählt als gewünscht ist. 10

11 3.2 Inter-Type-Declaration Mit den Advices war es uns möglich, dynamisch in die Programme einzugreifen. Um die statische Struktur eines Programms zu verändern, bedienen wir uns der Funktionalität von Inter-Type-Declarations. Dieses Feature von AspectJ, welches aufgrund seiner Funktion auch als statische Joinpoints bezeichnet wird, ermöglicht den Eingriff in die Klassenhierarchie und in den Aufbau eines Programms. Inter-Type-Declarations werden immer zur Übersetzungszeit ausgewertet. Eine grundlegende Möglichkeit Inter-Type-Declarations zu nutzen, ist das Hinzufügen von Attributen, Konstruktoren oder Methoden zu Klassen. Um einer bestehenden Klasse OnType einen neuen Konstruktor hinzufügen, bedienen wir uns folgender Syntax: [<modifier>] OnType.new(<parameter>) [throws TypeList]{<body> Hierbei muss beachtet werden, dass OnType kein Interface sein darf, da Interfaces keine Konstruktoren haben können. Ebenfalls ist es nicht möglich, einem Attribut aus der Klasse OnType, welche mit dem Schlüsselwort final deklariert wurde, einen Wert zuzuweisen. Wenn man einer Klasse ohne Konstruktor einen neuen Konstruktor, dem keine Variablen übergeben werden, hinzufügen will, kommt es zu einem Konflikt, da in Java konstruktorlose Klassen implizit den Konstruktor ihres Obertyps erben, dessen Rumpf super() enthält. Somit ist bereits ein gleich benannter Konstruktor vorhanden und es wäre unklar, welcher Konstruktor zur Initialisierung eines Objektes genutzt werden soll. Prinzipiell ist die Methoden-, Attribut- und Konstruktordeklaration nahezu identisch mit dem Vorgehen in Java. Um einer Klasse OnType eine neue Methode hinzufügen, wird eine ähnliche Syntax wie beim Konstruktor genutzt: [<modifier>] <rueckgabetyp> OnType.<id>(<parameter>) [throws TypeList]{<body> Im Gegensatz zum Konstruktor kann hierbei die Methode uneingeschränkt in Bezug auf ihre Schlüsselwörter einem Interface hinzugefügt werden. Das bedeutet, dass es auch möglich ist, einem Interface eine Methode zuzuweisen, die weder public noch abstract ist. public interface I { aspect A{ private void I.m( ) { System. e r r. p r i n t l n ( I m a p r i v a t e method + on an i n t e r f a c e ) ; void worksoni ( I n t e r f a c e i ){ i.m( ) ; 11

12 Obwohl wir einem Interface eine Methode, die mit dem Schlüsselwort private deklariert wird und einen Rumpf enthält, zuordnen, erhalten wir keine Fehlermeldung. Das Gleiche gilt ebenfalls für Attribute. Um einer Klasse oder einem Interface ein neues Attribut zuzufügen, nutzen wir folgende Syntax: [<modifier>] <typ> OnType.<id>[=<ausdruck>]; Auch hierbei gilt, dass wir ein Attribut einem Interface hinzufügen können, auch wenn es weder public noch static oder final ist. Nutzen wir in diesem Zusammenhang, in einer neu deklarierten Methode, einem Attribut oder im Konstruktor das Schlüsselwort this, so bezieht sich dies immer auf das ausgeführte OnType Objekt und nicht auf den Aspekt, in dem der jeweilige Code sich befindet. Somit würde natürlich auch ein Fehler gemeldet, wenn wir versuchen, this in einer statischen Methode zu nutzen. Was die jeweiligen Sichtbarkeiten betrifft, so muss beachtet werden, dass eine als private deklarierte Methode nicht für die Klasse sichtbar ist, zu der sie hinzugefügt wird, sondern nur für den jeweiligen Aspekt zugänglich ist. Allgemein gelten die angegebenen Sichtbarkeiten immer aus der Sicht des Aspektes. Geben wir für eine Methode die default Sichtbarkeit an, so bedeutet dies, dass alle im gleichen Paket wie der Aspekt befindlichen Klassen oder Aspekte auf diese Methode zugreifen können. AspectJ unterstützt keine protected Sichtbarkeit. Da sich die Sichtbarkeit auf den jeweiligen Aspekt bezieht, können sowohl im Aspekt als auch in der Klasse selbst zwei gleichnamige Methoden oder Attribute mit dem Schlüsselwort private deklariert werden. Aufgrund dessen, dass der Aspekt die Methode der Klasse nicht sehen kann und die Klasse wiederum nicht die im Aspekt definierte Methode, kann es bei den Aufrufen zu keinem Konflikt kommen. Hieraus ergibt sich nur eine Problematik, wenn ein Interface verlangt, dass eine Klasse eine private Methode definiert. Ein Konflikt kann entstehen, wenn gleichnamige nicht private Attribute oder Methoden im Aspekt und in der betreffenden Klasse definiert sind. Hierbei ist unklar, auf welche Methode oder Attribut sich ein bestimmter Aufruf bezieht. Der Aufruf ist somit mehrdeutig und es tritt ein Konflikt zur Übersetzungszeit auf. Dies kann zumindest unter Aspekten vermieden werden, wenn ein Aspekt Vorrang vor anderen hat. Eine weitere Funktionalität von Inter-Type-Declarations ist das Eingreifen in die Klassenhierachie und das Hinzufügen zusätzlicher Compiler-Meldungen. declare parents: <typepattern> (extends impements) <type>; Mit dieser Anweisung kann man in die Vererbungshierarchie einer Klasse eingreifen oder ihr ein Interface hinzufügen. d e c l a r e parents : B extends A; d e c l a r e parents : (B C) implements I ; declare warning: <pointcut> : <string>; 12

13 Sobald ein Joinpoint aus Pointcut in einem Programm besteht, wird an dieser Stelle eine Compiler Warnung ausgegeben. d e c l a r e warning : set ( S t r i n g Stock. f i l e n a m e ) &&! within ( Stock ) : Don t change f i l e n a m e ; declare error: <pointcut> : <string>; Diese Anweisung funktioniert ähnlich wie declare warning, bis auf dass ein Compiler Fehler anstatt einer Warnung ausgegeben wird. declare soft: <type> : <pointcut>; Die Ausnahmen vom Typ, welche bei den von Pointcut ausgewählten Joinpoints geworfen werden, werden abgeschwächt und von org.aspectj.lang.softexception umschlossen. Dies bedeutet, dass die Ausnahmen zu Laufzeitausnahmen abgeschwächt werden, da SoftException ein Untertyp von RunTimeException ist. Somit werden diese nicht mehr vom Übersetzer überprüft. d e c l a r e s o f t : ClassNotFoundException : execution ( void ( ) ) ; declare precedence : <typepatternlist>; Mit dieser Anweisung kann man bestimmen, welcher Aspekt Vorrang vor einem anderen hat. Um festzulegen, dass zwei Aspekte keine Übereinstimmung in der Auswahl ihrer Joinpoints haben, mit anderen Worten, vollkommen unabhängig voneinander sind, kann man ihnen gegenseitig Vorrang vor einander gewähren. d e c l a r e precedence : B, A; d e c l a r e precedence : A, B; Somit ist es unmöglich, dass B und A die gleichen Joinpoints nutzen. 4 Praktischer Nutzen von AspectJ 4.1 Sicherheit Bei der Entwicklung von Softwareprojekten spielt nicht selten sicherheitsrelevanter Code eine entscheidende Rolle. In größeren Anwendungen muss gewährleistet werden, dass unter anderem der Anwender derjenige ist, für den er sich ausgibt(authentifizierung) und dass die Daten, die er sieht und die Funktionen, die er nutzen kann, auf sein Profil zugeschnitten sind(autorisierung). Besonders in Bezug auf die Einschränkung von Funktionen kann AspectJ elegante Lösungen liefern. Hierbei kann man gewährleisten, dass ausschließlich Aktionen vom Benutzer einsehbar und ausführbar sind, für welche er die nötige Berechtigungen hat. Beispielsweise wäre es für eine Applikation für eine Personalverwaltung wichtig, dass nicht alle Nutzer die gleichen Funktionen nutzen können. Es sollte 13

14 zum Beispiel nicht jedem Nutzer gestattet sein, die Gehaltszahlungen zu modifizieren, dennoch wäre es durchaus möglich, dass die Nutzer eigenständig ihre Adressen ändern dürfen. Hierbei wäre es nützlich, bestimmte Aktionen je nach Berechtigung aktivieren und deaktivieren zu können. In Java ist es z.b. möglich, Swing-Elemente zu aktivieren und zu deaktivieren. Da jedes Element, welches die Klasse Component als Obertyp hat, die Methode add() und isenabled() erbt, kann man Pointcuts auf die betreffenden Methoden legen. Mit einem Pointcut auf die Methode add() könnte man bereits beim Hinzufügen von Swing-Elementen wie z.b. Buttons, Checkboxen und Listen, diese mit Hilfe von setenabled() auf false setzen. Möchte man Veränderungen auch während der Laufzeit zulassen, so wäre es nötig, einen Pointcut auf isenabled() zu setzen. Da es durch eine Veränderung der Berechtigung auch zur Änderung der Verfügbarkeit des Swing-Elementes kommt, müssen hierbei zusätzliche repaint()-aufrufe beachtet werden. In Eclipse wäre es auch möglich, dass vom Nutzer ausführbare Funktionen das Interface IAction implementieren. Dadurch kann man einen Pointcut auf isenabled() oder auf run() und runwithevent() legen, dessen zugehöriger Advice die Berechtigungssteuerung übernehmen könnte. Wie man jedoch im Artikel Security Does Matter von Peter Friese, Martin Lippert und Heiko Seeberger[6] nachlesen kann, ist dies mit weiteren Schwierigkeiten verbunden, da AspectJ ursprünglich nicht mit Blick auf das Plug- In Konzept von Eclipse entwickelt wurde. Das Hauptproblem liegt hier bei dem Classloading-Mechanismus von Eclipse, da dieser nicht von vornherein das Zusammenspiel von Aspekten und Klassen in verschiedenen Bundles betrachtet. Jedoch ist es möglich, mit dem AJEER-Projekt[1] Eclipse um Loadtime- Weaving zu erweitern und diese Problematik zu behandeln. AspectJ ermöglicht somit sicherheitsrelevanten Code effizient von den Klassen zu trennen und somit mehr Übersichtlichkeit und Verständlichkeit zu erreichen. 4.2 Caching Caches dienen zur schnellen Bereitstellung von bereits einmal verlangten Daten, um die Zugriffsgeschwindigkeit einer Anwendung zu optimieren. Dabei werden die Daten in einem temporären Speicher zwischengelagert. Die Gründe hierfür sind, dass entweder das Laden der Daten aus einem Hintergrundspeicher eine weitaus längere Zeit in Anspruch nehmen würde oder die Daten aus einer komplexen Berechnung entstammen. Der Cache verringert durch das Zwischenspeichern einmal erlangter Daten, dass diese wieder geladen bzw. berechnet werden müssen und verringert somit die Zugriffszeit einer Anwendung. In der Objektorientierung übernimmt normalerweise ein Modul das Laden der Daten bzw. die Berechnung. Möchte man nun das Caching von Daten ermöglichen, müsste das Modul zusätzlich das Laden und Speichern in einen Cache implementieren. Diese Anforderungen haben jedoch mit dem Modul selbst wenig zu tun. Mit Hilfe der aspektorientierten Programmierung lassen sich diese Belange in einen Aspekt auslagern, der das Caching übernimmt. Dazu wird ein Pointcut 14

15 auf die Methode gelegt, welche die Daten aus dem Hintergrundspeicher lädt. Ein zugehöriger around()-advice kann jetzt überprüfen, ob die gewünschten Daten nicht bereits im Cache vorhanden sind und falls dies der Fall ist, die Daten aus dem Cache zurückgeben und somit einen unnötigen Zugriff auf den Hintergrundspeicher vermeiden. Wenn die Daten nicht im Cache sein sollten, kann der Joinpoint mit Hilfe von proceed() ausgeführt werden. Im Anschluss muss dann nur noch das Objekt für den nächsten Zugriff im Cache gespeichert und das Ergebnis zurückgegeben werden. 4.3 Ersetzung ereignisgesteuerter Programmierung Durch den Einsatz von aspektorientierter Programmierung ist es möglich, Event-Handling komplett zu ersetzen. Um dies nachvollziehen zu können, muss man sich zunächst bewusst machen, wozu Event-Handling eingesetzt wird. In verschiedenen Projekten ist es oft nötig, ein Objekt A über Veränderungen an einem Objekt B zu informieren, im Besonderen auch ohne dass B Objekt A überhaupt kennt. Um dies zu ermöglichen, müssen Objekte, in unserem Fall B, die über Benachrichtigungen informiert werden möchten, die Schnittstelle Listener implementieren und bei dem zu überwachenden Objekt registriert werden. Dieses gesamte Vorgehen wird bei der Aspektorientierung überflüssig, da in unserem Beispiel ein Aspect C die zu überwachenden Ereignisse für das Object B definieren(pointcut) und für jedes überwachte Ereignis den auszuführenden Code implementieren kann(advice). Dies hat den unübersehbaren Vorteil, dass keine zusätzlichen Interfaces, Methoden oder eine Registrierung erforderlich sind. 4.4 Software-Tests Die aspektorientierte Programmierung kann sich ebenfalls beim Testen kleinerer und größerer Softwareprojekte als hilfreich erweisen. Die Möglichkeiten, welche sich in diesem Anwendungsfeld erschließen, wären beispielsweise das Tracing privater Attribute, das Implementieren von Mock-Elementen (Platzhalter für echte Objekte in Unit-Tests) oder das Hinzufügen von Methoden und Attributen. AOP ersetzt hierbei nicht die Unit-Tests, kann diese jedoch im hohen Maße vereinfachen und verbessern. Möchten wir die Veränderungen an einer als private deklarierten Methode außerhalb dessen Moduls verfolgen, so müssen wir im konventionellen Java zusätzliche öffentliche get()-methoden hinzufügen. Mit diesem Vorgehen gewähren wir jedoch auch anderen Modulen Zugriff auf diese Variablen, was wir unter Umständen vermeiden wollten. Bei AspectJ können wir einen Aspekt mit dem Schlüsselwort privileged ausstatten. Dieses Schlüsselwort hebt alle Zugriffseinschränkungen für den Aspekt auf und ermöglicht uns den Zugriff auf alle Attribute und Methoden einer Klasse. public class S e c r e t { private S t r i n g secretmsg ; 15

16 public void setmsg ( S t r i n g message ){ this. secretmsg=message ; public privileged aspect SecretAspect { pointcut c o n t r o l s e c ( S e c r e t s e c r ) : c a l l ( S e c r e t. setmsg (.. ) ) && target ( s e c r ) ; after ( S e c r e t s e c r ) : c o n t r o l s e c ( s e c r ){ i f (! ( s e c r. secretmsg ). e q u a l s ( nevermore ) ) System. out. p r i n t l n ( f a l s e ) ; In diesem Beispiel überprüfen wir, ob unsere String-Variable secretmsg auf nevermore gesetzt wurde. Sollte dies nicht der Fall sein, wird false ausgegeben. Ohne privileged könnten wir nicht auf die Variable secretmsg zugreifen. Da uns das Schlüsselwort den kompletten Zugriff ermöglicht, muss der Einsatz von privileged sorgfältig geschehen. Im Klartext bedeutet das, dass der Einsatz von AspectJ nicht dazu verleiten sollte, Design-Fehler mit Hilfe von privileged zu überdecken. Oftmals werden bei Unit-Tests nur einzelne Codeabschnitte getestet. Es ist daher nicht immer wünschenswert, wenn hierbei komplexe Berechnungen oder Aufrufe von Datenbanken durchgeführt werden müssen, die mit den Tests selber nichts zu tun haben oder selbst noch fertig getestet werden müssen. Hierfür ist es möglich, bestimmte Methoden oder Objekte mit AspectJ auszutauschen. Wie wir bereits wissen, ermöglicht uns der around()-advice, Code anstelle des ausgewählten Joinpoints auszuführen. public class S e c r e t { private S t r i n g secretmsg ; public void setmsg ( S t r i n g message ){ this. secretmsg=message ; public privileged aspect SecretAspect { pointcut s e c ( S e c r e t s e c r ) : c a l l ( S e c r e t. setmsg (.. ) ) && target ( s e c r ) ; void around( S e c r e t s e c r ) : s e c ( s e c r ){ s e c r. secretmsg= nevermore ; In diesem Codeabschnitt würden wir unsere geheime Nachricht immer auf nevermore setzen und können somit für unsere Unit-Tests festlegen, dass unsere Variable bereits einen korrekten Wert hat und dadurch das Hauptanliegen auf die getesteten Methoden legen. 16

17 Des Weiteren kann das Testen von Softwareprojekten durch das Hinzufügen von Methoden und Attributen mit Inter-Type-Declarations oder dem Erstellen von Mock-Elementen unterstützt werden. 4.5 Programmierrichtlinien Programmierrichtlinien sind in größeren Entwicklerteams aus Gründen der Überschaubarkeit des Quelltextes und der Qualitätssicherung unerlässlich. Die Durchsetzung dieser Richtlinien ist jedoch aufgrund verschiedener Umstände wie räumliche Verteilung und Anzahl der Mitarbeiter erschwert. Um sicher zu stellen, dass die Anwendung dieser Richtlinien trotzdem gewährleistet wird, bietet aspektorientierte Programmierung einen eleganten Ansatz. Die Möglichkeit mit AspectJ genau überprüfen zu können, aus welchen Klassen Aufrufe erfolgen, versetzt uns in die Lage, diese Aufrufe einschränken zu können. Möchten wir beispielsweise verhindern, dass außerhalb der Klasse Stock oder Storehouse die Methode insertstock() aufgerufen wird, können wir dies mit folgender Inter-Type-Declaration durchführen. d e c l a r e e r r o r : c a l l ( void Stock. i n s e r t S t o c k ( String, String, S t r i n g ) ) &&! ( within ( Storehouse ) within ( Stock ) ) : Manipulation o f Stock i s not allowed ; In diesem Beispiel wird das Aufrufen der Methode insertstock mit Hilfe eines Compiler Fehlers unterbunden, wenn der Aufruf nicht innerhalb von Storehouse oder Stock ist. Anstatt gleich Compiler Fehlermeldungen auszugeben, kann man auch einfache Warnungen nutzen. d e c l a r e warning : ( set ( public. ) get ( public! f i n a l. ) ) : Avoid using p u b l i c a c c e s s to f i e l d s! ; Hier wird von dem Nutzen von als public gesetzten Attributen abgeraten. Da die Einhaltung der Regeln bei jedem Kompilierungsvorgang überprüft wird, können aufwändige Nachkontrollen der Anwendung eingeschränkt und eine kostengünstigere Entwicklung gewährleistet werden. 5 Vor- und Nachteile aspektorientierter Programmierung Die Verknüpfung der aspektorientierten und objektorientierten Programmierung hat sowohl Vor- als auch Nachteile. Einer der größten Kritikpunkte an AOP ist die Einbuße an Performance in einer Anwendung. Inzwischen ist es jedoch durch die ständige Weiterentwickelung von AspectJ gelungen, dass der Unterschied zwischen einem Programm ohne und einem Programm mit Einsatz dieses Konzeptes kaum mehr signifikant ist. Im Gegenteil, AspectJ kann bestimmte Anforderungen eleganter implementieren und sogar Performance gewinnen. Ein weiterer Kritikpunkt ist eine reduzierte Nachvollziehbarkeit der Programme, da 17

18 AspectJ die Regel verletzen kann, dass sich sämtliche Attribute und Methoden einer Klasse in deren Rumpf oder deren Oberklassen befinden. Auch Veränderungen an der Vererbungshierarchie können den Überblick erschweren. Bei korrekter Anwendung kann dieser Nachteil jedoch minimiert werden. Des Weiteren sollte man sich bewusst sein, dass Aspekte auch unerwünschte Wechselwirkungen aufeinander haben können, die im Voraus nicht vorhergesehen wurden. Ein unübersehbarer Vorteil ist selbstverständlich die Loslösung von modulübergreifenden Anforderungen aus den einzelnen Klassen. Dies wiederum erhöht die Übersichtlichkeit enorm, da, wie unser Einführungsbeispiel verdeutlichtet, nicht mehr sämtliche Klassen von Aufrufen durchzogen sind, die mit ihrer eigentlichen Funktionalität nicht in Verbindung stehen. Dies spielt für eine kostengünstige und termingerechte Entwicklung von Software-Anwendungen eine tragende Rolle. Ein weiterer Vorteil ist, dass Veränderungen leicht zurückgenommen werden können, da die Objekte nicht direkt verändert werden. Auch in den Bereichen Programmierrichtlinien und Qualitätssicherung bietet AspectJ mehrere Vorteile, wie bereits in den vorherigen Kapiteln erläutert wurde. 6 Fazit Die Bedeutung von aspektorientierter Programmierung und AspectJ wird auch in Zukunft noch anwachsen, da aus ihrer Anwendung viele Vorteile entstehen, wie verbesserte Wartbarkeit, Übersichtlichkeit und eine bessere Strukturierung von Softwareprojekten. Durch die Trennung von Aspekten und Modulen können neue elegantere Ansätze bei der Betrachtung von bekannten Softwareproblemen entstehen. Besonders bei der Entwicklung von größeren Projekten erscheint der Einsatz dieser Technologie als besonders sinnvoll. Auch wenn AOP bisher noch in der Entwicklung ist, so ist es dennoch zweckmäßig, sich bereits jetzt mit diesem Konzept zu beschäftigen, da der Einfluss sich im Laufe der Zeit wohl immer mehr erhöhen wird. Wie in dieser Arbeit sichtbar wurde, gibt es reichlich Einsatzmöglichkeiten für aspektorientierte Programmierung. Dennoch ist das Erlernen dieser Technologie natürlich mit einem gewissen Aufwand verbunden, da auch von erfahrenen Programmierern eine andere Denkweise benötigt wird als bei der objektorientierten Programmierung. In größeren Projekten wird dieser zusätzliche Aufwand jedoch von dem Nutzen von AOP eingeholt. Alles in allem ist es sinnvoll, die weitere Entwicklung von aspektorientierter Programmierung zu beobachten und sich mit diesem Thema weiterhin zu beschäftigen. Literatur [1] AJEER, [2] Ron Bodkin. AOP@Work: Next steps with aspects. IBM DeveloperWorks, library/j-aopwork16. 18

19 [3] The Eclipse Foundation. AspectJ Development Tools, [4] The Eclipse Foundation. The Eclipse Foundation. The AspectJ Project, [5] Nicholas Lesiecki. Improve modularity with aspect-oriented programming. IBM DeveloperWorks, library/j-aspectj/. [6] Heiko Seeberger Peter Friese, Martin Lippert. Security Does Matter. eclipse magazin ( [7] SpringSource. Spring - eliminating enterprise java complexity. [8] The AspectJ Team. AspectJ Developers Notebook. adk15notebook/index.html. [9] The AspectJ Team. The AspectJ Development Environment Guide. devguide/index.html. [10] The AspectJ Team. AspectJ Documentation and Resources. [11] The AspectJ Team. AspectJ Programming Guide. progguide/index.html. 19