Hochschule Furtwangen

Transkript

1 Hochschule Furtwangen Seminar Aktuelle Themen der Informatik Ausarbeitung Tools für Aspekt-orientierte Programmierung Harald Schwecht, CN

2 Inhaltsverzeichnis 1. Einleitung Begriffserklärung Core Concern Crosscutting Concern Phasen der Aspekt-Orientierung Identifikation Separation Integration Schwierigkeit der Anforderungs-Separation Separation von Crosscutting Concerns durch AOP Grundlegendes zu AOP Elemente von AOP Join Points Pointcuts Advices Inter-type Declarations Aspekte AOP Tools & Frameworks Unterscheidungsmerkmale verschiedener AOP Lösungsansätze AspectC/C AspectJ AOP-Beispiel ActiveAspect Asbro AspectWerkz JBoss AOP Spring AOP weitere AOP Tools Übersicht Syntax Überblick Sprach-Mechanismus Fazit Quellen

3 1. Einleitung Wieso ist AOP derart nützlich? AOP ist Programmierung basierend auf der Identifizierung und Erzeugung von Aspekten. Wichtig ist das Verständnis der zugrunde liegenden AOP-Konzepte und wie AOP Objektorientierte Programmierung und -Designs ergänzt, um Java Code wartbarer und robuster zu gestalten. AOP ersetzt oder verlagert nicht die OOP, sondern ergänzt sie. Aus diesem Grund kann man AOP als den nächsten natürlichen Schritt der Software-Entwicklung über die OOP hinaus betrachten. Mit konventionellen Objekt-orientierten Techniken sind logisch zusammengehörige Softwareelemente oft nicht modularisierbar. Eine schlechte Modularisierung zieht einige negative Effekte nach sich, auf die diese Ausarbeitung ebenfalls hindeuten soll. Um die Modularisierung zu fördern, existieren unterschiedlich ausgeprägte Werkzeugen für die Softwareentwicklung. Diese werden im Einzelnen besprochen und die unterschiedlichen Selektionssprachen und Adaptionsmechanismen verglichen, sowie ihre Eigenschaften aufgeführt. 3

4 2. Begriffserklärung 2.1. Core Concern Core Concerns (engl. core concern, "Kernfunktionalität") sind die eigentliche Kernlogik (Packages, Classes oder Source Code) des Programms, sozusagen die reine Unternehmenslogik Crosscutting Concern In der AOP stößt man oft auf den Begriff Crosscutting Concerns (=CCC, "übergreifende Anforderung", quer schneidende Kernfunktionalität). Solche CCC wären z.b. Anforderungen wie Fehlerbehandlung, Performance, Sicherheit, Transaktions-Management oder Logging. Sie sind zur eigentlichen Kernlogik des Programms "orthogonal" zu betrachten. Sie schneiden diese somit (engl. crosscut) und lassen sich nicht eindeutig einem Software Modul zuordnen Phasen der Aspekt-Orientierung Die Aspektorientierung kann man in drei grundlegende Phasen unterteilen: Identifikation Separation Integration 3.1. Identifikation Nutzung verschiedener Verfahren zur Erkennung von Core- und Crosscutting Concerns Separation Definition, modularer Entwurf und Implementation aller Concerns. Modular implementierte Core Concerns werden Komponenten genannt. Crosscutting Concerns werden demzufolge als die eigentlichen Aspekte bezeichnet. Zusätzlich werden in dieser Phase notwendige Integrationsregeln definiert, bevor es in die Integrationsphase geht Integration Die in der Separationsphase definierten Regeln dienen nun dem Zusammenfügen der Concerns (implementierte Komponenten und Aspekte) zum Gesamtsystem. Ein prägnanter Begriff in der AOP bezeichnet speziell die Integration, dieser lautet "Weaving" (= das Weben) und beschreibt bildlich das Vorgehen in der Integration. 4. Schwierigkeit der Anforderungs-Separation Wieso geschieht das Vermischen von Anforderungen bei der OOP? Zum einen weil die OOP Partitionierungs- und Modularisierungs-Mechanismen liefert, welche lediglich auf Zustände bzw. Daten und Verhalten basieren. Zum anderen weil Verfahren existierender Programmiersprachen und -designs keine brauchbaren Instrumente bieten, um auf einfache Weise Crosscutting Concerns sauber zu trennen. Diese Module liegen in der OOP ungekapselt, verstreut im ganzen Code. Diese Tatsache wirkt sich somit negativ auf die Wartbarkeit, die Wiederverwendbarkeit, u.u. auch auf die Nachvollziehbarkeit und das Entdecken von Fehlerquellen aus. 4

5 Kernfunktionalität (Core Concern) Applikation in der Objekt-orientierten Programmierung (OOP) Modul 1 Modul 2 modulübergreifende Anforderungen (Crosscutting Concerns) Sicherheit Logging Echtzeitverhalten Abbildung 1: Ansatz in der OOP 5. Separation von Crosscutting Concerns durch AOP AOP unterstützt die Separation und die Organisation des Source Codes, der mit diesen "übergreifende Anforderung" gelöst werden muss. Durch die Erzeugung von Aspekten erfolgt eine Modularisierung des Codes. Dies könnte man mit der Gruppierung in Verbindung stehenden Zustände und Verhaltensweisen innerhalb Klassen in der OOP vergleichen. Dadurch wird erreicht, dass solche Crosscutting Concerns (z.b. die Sicherheit oder das Logging betreffend) in spezifischen Aspekten und Objekten enthalten sind und nicht mehr - die Unternehmenslogik "verschmutzend" - vermischt die Applikation durchziehen. Kernfunktionalität (Core Concern) Modul 1 Modul 2 Sicherheit Logging Echtzeitverhalten Aspekt- Weber Komponenten Applikation in der Aspekt-orientierten Programmierung (AOP) modulübergreifende Anforderungen (Crosscutting Concerns) Modul 1 Aspekte Abbildung 2: Ansatz in der AOP Modul 2 5

6 6. Grundlegendes zu AOP Um Crosscutting Code auszuklammern, müssen AOP-basierende Lösungen: ermöglichen, dass Crosscutting Code in den Abarbeitungsablauf der Unternehmenslogik einwirken kann, diesen dynamisch einwirkenden Code berechtigen dessen Subsysteme aufzurufen, das Verpacken und die Organisation dieses zusätzlichen Codes zu ermöglichen ohne die Unternehmenslogik zu beeinflussen Zusätzlich muss es eine Möglichkeit der Beschreibung geben, wo und wann Crosscutting Code angelegt wird, sowie sicher zu stellen, dass dieser Code Zugriff zu Kontextinformationen während der Abarbeitung hat. Diese Merkmale erfüllen heutige AOP-Systeme. Sie fangen zur Laufzeit die Ausführung der Applikation ab und wenden dynamisch eigenen Crosscutting Code an. Am Beispiel von AspectJ - einem Aspekt-orientierten Framework für Java - kann wo und wann dies geschehen soll der Entwickler durch Spezifizierung von Pointcuts festlegen, die wiederum Join Points auswählen. 7. Elemente von AOP 7.1. Join Points Join Points sind spezielle Punkte zur Laufzeit, an denen Crosscutting Code eingesetzt werden kann. Die möglichen Join Points sind von den eingesetzten AOP Tools und Frameworks abhängig. Es gibt einerseits statische und andererseits dynamische Join Points. Speziell für AspectJ, Join Points möglich bei: Methodenaufruf Methodenausführung Aufruf eines Exception Handlers Ausführung eines Exception Handlers Konstruktoraufruf Konstruktorausführung Feld auslesen Feld schreiben Join Points verbunden mit Methodenaufruf haben früher Zugriff zur auszuführenden Kontextinformation als der tatsächliche Methodenaufruf. Join Points verbunden mit Methodenausführung haben Zugriff zur auszuführenden Kontextinformation innerhalb des Methodenrumpfs. Allerdings können Join Points nicht direkt genutzt werden, stattdessen müssen sie durch Anwendung von Pointcuts ausgewählt werden Pointcuts Pointcuts spezifizieren das "wo und wann" des Einsetzens von Crosscutting Codes. Sie wählen/identifizieren eine Menge von Join Points. Speziell für AspectJ (Deklaration innerhalb aspect oder class): 6

7 call(signature) wählt Join Points wenn spezielle(r) Methode/Konstruktor aufgerufen wird execute(signature) wählt Join Points wenn spezielle(r) Methode/Konstruktor ausgeführt wird get(signature) wählt Join Points wenn spezielles Feld gelesen wird set(signature) wählt Join Points wenn spezielle Feld geschrieben wird handler(type-pattern) wählt Join Points wenn der Exception Handler mit dem "Throwable type-pattern" ausgeführt wird Signature und type-pattern können mit Jokerzeichen ergänzt werden, um u.u. möglichst viele Methoden, Konstruktoren oder Subtypen abzudecken. Mehrere Pointcuts können mit && oder Operatoren kombiniert werden Advices Advices knüpfen einzusetzenden Crosscutting Code mit den durch Pointcuts selektierten Join Points. Der Advice beinhaltet den auszuführenden Crosscutting Code und bestimmt durch seine Eigenschaft wann es in Abhängigkeit zum - vom Pointcut - gewählten Joint Point ausgeführt wird. Speziell für AspectJ: before() after() around() Crosscutting Code VOR dem/den gewählten Joint Point(s) ausführen Crosscutting Code NACH dem/den gewählten Joint Point(s) ausführen Crosscutting Code AM ORT des/der gewählten Joint Point(s) ausführen, mit der Möglichkeit die Ausführung des/der Joint Point(s) zu umhüllen oder auszulassen Typischerweise wird ein durch den Join Point betroffener Code und durch den Crosscutting Code ersetzter Code als "advised" (engl. für angewiesen) bezeichnet Inter-type Declarations Inter-type Declarations sind von AspectJ zusätzlich einsetzbare Teile (Methoden/Felder) zu einer existierenden Java-Klasse oder Typs. Diese erscheinen als wären sie direkt innerhalb der ursprünglichen Klasse oder Typs implementiert Aspekte Aspekte werden auf ziemlich gleicher Weise definiert wie Klassen. Im Aspekt können Pointcuts, Advices und Inter-type Declarations zusammengepackt werden. Zusätzlich kann ein Aspekt Felder und Methoden (static/non-static) haben und es kann abstrakt sein. Klassen oder Aspekte können sogar soweit ausgebaut werden dass sie Aspekte erzeugen. Ein Aspekt stellt somit eine gut modularisierte Crosscutting Struktur dar! 7

8 8. AOP Tools & Frameworks 8.1. Unterscheidungsmerkmale verschiedener AOP Lösungsansätze AOP Lösungsansätze unterscheiden sich in: Zugriff Zusammenfügen Benennung und Abstraktion von Join Points. Zusätzlich in: Syntax AOP Reifegrad Release Historie: AspectJ, AspectWerkz, JBoss AOP, Spring AOP, 1.Release in 2001 vom AOP Team beim Xerox PARC 1.Release in 2002 von BEA Systems 1.Release in 2004 als eine Ergänzung zum JBoss Application Server 1.Release in 2004 als eine Ergänzung zum Spring framework 8.2. AspectC/C++ AspectC/C++ Development Tools (ACDT) basiert auf dem C/C++ Development Tools (CDT) Plugin und unterstütz integriert als Eclipse Plugin - zusätzliches Syntax Highlighting sowie Extended Outlining, was bewirkt dass Aspekte, Advices und Pointcuts speziell angezeigt werden. Unterstütz wird Eclipse ab v3.1.x, darunter gibt es allerdings eine ältere Version von AspectC/C++ mit der Version AspectJ AspectJ ist eine Erweiterung von Java um die Aspektorientierung. AJDT ist als Eclipse Plugin verfügbar. Aspekte sind hier eine Kombination aus Java-Code und AspectJ-Code. Durch die vom AspectJ Compiler durchgeführte Verwebung auf Source-Code-Ebene, werden Aspekte in Java-Bytecode eingebunden. Es gibt dabei zwei wesentliche Compiler: ajc: im Eclipse AspectJ Projekt enthalten => aspectjrt.jar muss im Classpath/Eclipse existieren! (wird mitkopiert) abc: (AspectBench Compiler) erweiterbarer optimierender Compiler Es existieren zwei nennenswerte Portierungen auf Lisp (AspectL) und Ruby (AspectR). 8

9 8.3.1 AOP-Beispiel HelloWorld.java: Am Beispiel einer HelloWorld! Implementation in AOP können die eben angesprochenen Elemente deutlich erkannt und verstanden werden. Zuallererst wird ein neues AspectJ Projekt erstellt. Gleich darauf eine neue Java Klasse "HelloWorld" und eine Methode sayhello() erzeugt. In main() wird die Methode dann als ein neues Objekt der Klasse aufgerufen. Hinweis: Wichtig an dieser Stelle ist, dass man das Projekt bisher testet bzw. die class-datei erzeugt, da sonst später das Advice nicht richtig gefunden wird! Abbildung 3: HelloWorld.java World.aj Darauf folgend wird eine neue AspectJ Klasse "World" erzeugt. Ein benutzerdefinierter Pointcut "greeting():" muss nun deklariert werden, der die Ausführung jeglicher Methoden namens HelloWorld.sayHello(..) mit jeglichem Rückgabewert (durch Wildcard Stern ) und übergebenen Argumenten (gekennzeichnet durch die Parameter- Wildcard mit 2 Punkten) anpasst. Der Pointcut ist wie bekannt nötig, um nach der Ausgabe von "Hello " etwas zu tun. Was getan wird und wie in Bezug zum Join Point, entscheidet nun ein Advice afterreturning, und zwar die Ausgabe von World! nach dem Join Point Hello. 9

10 Abbildung 4: World.aj 8.4. ActiveAspect Abbildung 5: Darstellung von Aspekten in ActiveAspect ActiveAspect ist ein Eclipse Plugin für die Darstellung von Aspekten ähnlich der UML- Diagramme. Daraus werden die Zwischenbeziehungen nicht nur der Klassen des Projekts, sondern auch die Advices der Aspekte zu einzelnen Klassen deutlich. 10

11 8.5. Asbro Asbro ist ein Eclipse Plugin um in erster Stelle ein Treemap des Projekts darzustellen, kann jedoch, da es mindestens Eclipse v3.1 und AJDT v1.2 (Aspect Java Development Tool) benötigt, auch für die Darstellung von Aspekten innerhalb des Treemaps genutzt werden. Das Treemap View kann zusätzlich neben dem AJDT Editor in Eclipse geöffnet werden AspectWerkz AspectWerkz wurde kombiniert mit dem AspectJ Projekt und führte dann zum AspectJ 5. Ziel war es eine größere Flexibilität betreffs Aspekt-Syntax zu erreichen, indem die Vorteile beider Frameworks dazu beitragen. AspectWerkz wird allerdings unabhängig weitergeführt. Falls AspectWerkz nicht als plugin für Eclipse genutzt wird, sind einige Libraries im Java Classpath nötig, d.h. nicht nur eine jar-datei wie es bei AspectJ der fall ist. Nachteil: Imports sind explizit nötig, da kein impliziter Import-Mechanismus (wie bei AspectJ) vorhanden ist: import org.codehaus.aspectwerkz.definition.pointcut; import org.codehaus.aspectwerkz.joinpoint.joinpoint; import org.codehaus.aspectwerkz.annotation.expression; import org.codehaus.aspectwerkz.annotation.*; //für Advices Einerseits sind bei AspectWerkz Deklarationen wie die Annotation von Java 5 möglich (siehe folgende Abb.), andererseits im Sinne der Kompatibilität ist die Annotation von Javadoc zu J2SE 1.4 möglich. XML wird als Deklaration von Integrations-Konfigurationen von Aspekten ebenso wie die Annotationen erlaubt (siehe Abbildung zu aop.xml). Abbildung 6: Authentication.java Abbildung 7: aop.xml 11

12 8.7. JBoss AOP Mit dem Eclipse Plugin Jboss AOP soll erreicht werden serverseitig Aspekt-orientierte Entwicklungen im Bereich Enterprise Java Bean (EJB) zu gewährleisten. Gerade in diesem Bereich macht die Modularisierung besonderen Sinn. Hervorzuheben ist dass der JBoss Application Server die AOP-Technik unterstützt, anders als die J2EE-Spezifikation anderer Server, die dies nicht unterstützen. Explizite Imports nötig, z.b.: import org.jboss.aspects.security.*; //z.b. alle Aspekte aus Security import org.jboss.aop.joinpoint.* import org.jboss.aop.pointcut.pointcut; import org.jboss.aop.advice.*; Abbildung 8: Authentication.java Abbildung 9: jboss-aop.xml 8.8. Spring AOP Durch Spring AOP erhält man eine stark auf XML aufbauende Implementierung, die dadurch jedoch feine Granularität betreffs Konfigurierbarkeit und Code-Geflecht erreicht. Ähnlich dem JBoss AOP in: Konfigurierung Erzeugung Starten Vorteile: komfortabel und minimal in Runtime-Konfiguration des Spring frameworks kein separater Launcher nötig Nachteil: Bei Nutzung von JDK Proxies sind lediglich von diesen Proxies abgerufene Objekte advisebar, d.h. um Advices auf andere Objekte legen zu können, ist die Implementation eines eigenen Interface nötig. Alternativ kann man es dem Framework überlassen, welches den CGLIB Proxy Support nutzt. 12

13 8.9. weitere AOP Tools LOOM.NET Aspect# HyperJ (IBM) COSMOS (IBM) JAC Project (Java Aspect Components) Übersicht Syntax Aspekt Inter-type Advice Pointcut Konfiguration Deklaration Deklaration Körper AspectJ Code.lst Inclusion List AspectWerkz aop.xml Annotation oder XML Java JBoss AOP String jboss-aop.xml Methode Spring AOP XML springconfig.xml Überblick Sprach-Mechanismus AspectJ AspectWerkz JBoss AOP Spring AOP Pointcut Matching signature, type pattern, subtypes, wildcard, annotation signature, instanceof, wildcard, annotation regulärer Ausdruck Pointcut Anreihung &&,,! &&, Advices before, after, after returning, after throwing, around around before, after returning, around, throws dynamischer Kontext this, target, args via reflective access instanziert durch VM, target, instance, control flow VM, class, instance, thread VM, class, instance, join point class, instance Erweiterbar keit Abstrakte Pointcuts overriding, advice bindings 13

14 9. Fazit Einige Frameworks müssen einen höheren Reifegrad erreichen, bevor sie allgemeine Akzeptanz finden. Tendenziell kann ein Entwickler in der Aspekt-Orientierung seine persönliche Gewichtung auf Tools mit weniger Java- und dafür mehr XML-Anteil legen oder umgekehrt, wenn es darum gehen soll alles in einem Binary hinterlegen zu können. Glücklicherweise wird dies durch die Verwebung von Aspekten besonders bei dem Tool AspectJ durch den Aspekt-Compiler erfüllt. Es mag deutlich effizienter bzw. schneller sein eine XML-Datei mit Konfigurationen auszutauschen anstatt Java Source Code auszutauschen und dann zu kompilieren. Andererseits fühlt es sich mit AspectJ mehr nach Java-Programmierung an Aspekte zu deklarieren. Wenn man besonders mit dem JBoss Applikation Server arbeitet, wird man um JBoss AOP nicht herumkommen, im Gegenteil, die Möglichkeit Aspekt-orientiert an die Erzeugung von Middleware heranzutreten birgt bei der Komplexität der heutigen Sicherheits- und Transaktionsmanagement-Anforderungen genügend Überzeugungskraft. Crosscutting Concerns getrennt von der Kernfunktionalität, wartbarer und weniger fehleranfälliger während der Implementierung, zu halten kann aus Sicht von Qualitäts- und Risiko-Management von IT-Projekten positiv auf die Fertigstellung vieler unter Umständen sonst gescheiterten Projekten wirken. Schließlich kann man feststellen, dass jedes Framework seine Eigenschaften hat und es liegt an einem selber bzw. an den Applikations-Anforderungen, welches man letztendlich für die Umsetzung wählt. 14

15 10. Quellen Vorgabe: JavaMVP03 - AOP tools comparison, IBM - An introduction to AOP, IBM Development Tools for AspectC/C Asbro - ActiveAspect - AspectWerkz - JBoss AOP Spring AOP 15