Aspektorientierte Programmierung mit Spring.NET und Aspect#

Transkript

1 Aspektorientierte Programmierung mit Spring.NET und Aspect# Dokumentation Viktor Steinwand (289650) David Hahn (289637) 1 von 28 David Hahn & Viktor Steinwand

2 Inhaltsverzeichnis 1. Was ist AOP? Crosscutting Concerns Symptome Nachteile Vorgehen beim AOP Crosscutting Concerns mit OO und AOP Join Point Modell Weitere Begriffe Pointcuts Advices Entwicklungsphase OO und AOP Arten von AOP Proxies und Kontexte Webe-basierte Ansätze Vorteile durch AOP Stärkere Modularisierung Klarere Trennung der Verantwortung Stärkere Wiederverwendung Höhere Produktivität Anwendungen Programmbeispiele Ein Beispiel des Loggings mit Spring.NET Ein Beispiel des Loggings mit Aspect# Entwicklungsstand Fazit Quellen Abbildungsverzeichnis Quellcodeverzeichnis von 28 David Hahn & Viktor Steinwand

3 1. Was ist AOP? In der Geschichte der Entwicklung der Programmiersprachen wurden immer wieder neue Konzepte der Programmierung und diese implementierende Hochsprachen entwickelt, angefangen bei der Programmierung in Assembler, über prozedurales und funktionales Programmieren, bis hin zu den heute aktuellen objektorientierten Sprachen. Der Zweck dieser Entwicklung war es nicht, den Rechnern eine erweiterte Funktionalität zu ermöglichen, sondern den Entwicklern die Arbeit zu erleichtern und somit eine bessere Effizienz in der Entwicklung der Software zu erzielen. Insbesondere erleichtert die Kapselung von Funktionalität dem Softwareentwickler die Entwicklung durch Erhöhung der Wartbarkeit und Wiederverwendbarkeit von existierendem Programmcode. Ein bemerkenswertes Merkmal aspektorientierter Softwareentwicklung ist dabei, dass es sich um kein eigenständiges Paradigma zur Softwareentwicklung handelt, weil es auf anderen Paradigmen aufsetzt. Beispielsweise lassen sich strukturierte, objektorientierte und funktionale Softwareentwicklung gleichermaßen um Aspekte erweitern. AOP ist sozusagen die Erweiterung heutiger bestehender Paradigmen (Objektorientiert, Prozedural / Imperativ) zur Modularisierung von Crosscutting Concerns (Kap. 2). Unter OOP betrachtet man Objekte als Modularisierungseinheiten. Die Crosscutting Concerns werden jedoch als nicht modularisierbare Objekte (Aspekte) gesehen. Im Gegensatz dazu betrachtet man die Aspekte unter AOP als Modularisierungseinheiten. Daraus folgt, dass eine wesentliche Aufgabe von AOP darin besteht, die Crosscutting Concerns als Aspekte zu modularisieren. Ein Aspekt ist ein Gesichtspunkt unter dem man etwas betrachtet. Diese können in verschiedenen Varianten auftreten: Ein Aspekt kann in gleicher Ausprägung mit mehreren Modulen verbunden werden (ein Aspekt für n Module) ein Aspekt wird in modulspezifischer Ausprägung mit Modulen verbunden (ein Aspekt in n Ausprägungen für n Module) auch Mischformen sind möglich Die aspektorientierte Programmierung bietet nun die Möglichkeit, solchen Aspektcode (die sogenannten Crosscutting Concerns) aus Modulen zu extrahieren und in Form von Aspekten zu modularisieren. 3 von 28 David Hahn & Viktor Steinwand

4 2. Crosscutting Concerns Eine Software hat grundsätzlich bestimmte Aufgaben/Anforderungen zu erfüllen. Diese Anforderungen kann man grob in zwei Bereiche gliedern. Die so genannten Core Concern gehören zum ersten Bereich und sind das Kern- Anliegen/Verantwortung oder funktionale Anforderungen. Als Beispiel in einer Geschäftsanwendung ist das die Geschäftslogik [Abbildung.1]. Diese stellen die primäre Aufgabe eines Entwicklers dar und lassen im Allgemeinen gut in einzelnen Funktionen kapseln. In der realen Welt sind die Core Concerns gut durch Objektorientierung abbildbar. Abbildung 1: Geschäftslogik Die zweite Anforderung an die Software stellen die querschneidenden Verantwortungen dar. Dazu gehören weitere Aufgaben an den Entwickler die technische Anliegen wie z.b. Logging, Persistenz, Ausnahmebehandlung etc. Diese Aufgaben sind systemweit verteilt und werden in AOP daher Crosscutting Concerns (querschneidende Verantwortlichkeiten) genannt. Abbildung 2: Crosscutting Concerns 4 von 28 David Hahn & Viktor Steinwand

5 Crosscutting Concerns werden so bezeichnet, weil sie quer durch alle logischen Schichten des Systems "schneiden". AOP ist das Werkzeug, um die logisch unabhängigen Belange auch physisch voneinander zu trennen. Dabei wird angestrebt, Code zu erzeugen, der besser wartbar und wiederverwendbar ist. Wenn man ein Problem mit Hilfe von Software lösen möchte, zerlegt man das Problem in seine Elemente und implementiert diese Elemente in einer Programmiersprache. Das kann auf verschiedene Arten geschehen, beispielsweise funktional, prozedural oder objektorientiert. In der objektorientierten Programmierung wird das Problem in Objekte zerlegt. Betrachten Sie als Beispiel das folgende Bild [Abbildung. 3], das einen Teil der Klassen, aus denen der Application-Container Apache Tomcat besteht, graphisch darstellt (jedes Rechteck entspricht einer Klasse). Die roten Bereiche sind jene Code-Abschnitte, die sich mit dem Parsen von XML beschäftigen. Sie sind gut gekapselt und in eine einzige Klasse verpackt. Abbildung 3: Quellcode des Apacheservers 5 von 28 David Hahn & Viktor Steinwand

6 Manchmal jedoch kommen einem gewisse Problemaspekte in die Quere, sie schneiden gewissermaßen mitten durch das Objektmodell und lassen sich nicht ordentlich herauskristallisieren. Ein gutes Beispiel ist das Logging ist, welches über den gesamten Code verteilt ist. Das bei AOP-Vorstellungen fast immer herangezogene Beispiel ist der Code, der in Tomcat für das Logging benutzt wird [Abbildung. 4]. Abbildung 4: Code, der in Tomcat für das Logging benutzt wird 2.1 Symptome Bei den Crosscutting Concerns erkennt man mehrere Symptome: Code Tangling (Code-Vermischung). Hier ist eine Klasse für mehrere Anliegen verantwortlich, d.h. dass in einer Klasse mehrere Anliegen benötigt werden. Abbildung 5: Code Tangling Code Scattering (Code-Verstreuung). Ein Anliegen ist über mehrere Klassen verteilt, d.h. dass z.b. Logging an mehreren Stellen (in mehreren Klassen) benötigt wird. Abbildung 6: Code Scattering 6 von 28 David Hahn & Viktor Steinwand

7 2.2 Nachteile Durch Code-Vermischung und -Verstreuung entstehen vielerlei Probleme, wie z.b. redundanter Code. Es finden sich gleiche oder ähnliche Code-Fragmente an vielen Stellen des Programmcodes. Dadurch erweisen sich Änderungen umfangreicher und fehleranfälliger. Ebenfalls ist das Debugging, die Wartung, Erweiterung und Refaktoring sind viel schwerer weil man einen identischen Code an mehreren Stellen ändern muss. Die Wiederverwendung und Produktivität ist um einiges geringer da man hier die Geschäftslogik und technische Details vermischt. Dadurch ist die Code- Qualität schlechter, da man hier mehr oder weniger beiläufige Implementierungen hat. 3. Vorgehen beim AOP Anschaulich kann man sich das Prinzip wie folgt vorstellen: ein Programm, gleichgültig ob prozedural oder objektorientiert, folgt einem Programmablaufplan, d.h. der Programmfluss ist an jeder Stelle durch lineare Folgen von Anweisungen (Codeblöcke) und Sprünge zwischen diesen (z. B. Methodenaufrufe) festgelegt. Ein Aspekt wäre hier soviel wie eine Schablone, die über diesen Originalplan gelegt wird und verschiedene Änderungen oder Ergänzungen am Ablaufschema vornimmt. Änderungen an der Schablone lassen den Originalplan unangetastet, die Schablone lässt sich jederzeit austauschen, mit anderen kombinieren oder wieder entfernen [Abbildung. 5]. Abbildung 7: Vorgehen beim AOP 7 von 28 David Hahn & Viktor Steinwand

8 3.1 Crosscutting Concerns mit OO und AOP Der auf OOP beruhende Ansatz schafft ein bestimmtes Grad der Codezerstreuung und der Verwirrung, in dem die Logik der Crosscutting Concerns in die Kernmodule eingebettet wird, was bei einer Änderung die Änderung der Kernmodule mit sich zieht. Hier kommt die Aspektorientierung ins Spiel: Man versucht unabhängig von den Objekten die Crosscutting Concerns in Form von Aspekten in das Modell einzubringen. Aspekte können ähnlich Klassen spezifiziert und zur Übersetzungszeit auf diese angewandt werden. Diesen Vorgang nennt man das Verweben (engl. Weaving) von Aspekten und Klassen. Man kann Änderungen an einem Aspekt vornehmen oder es sogar ersetzen, ohne die anderen Teile der Anwendung zu betreffen. 3.2 Join Point Modell Um Aspekte in Programmiersprachen einführen zu können benötigt man Punkte, an denen man in den bestehenden Code eingreifen kann. Diese Punkte werden als Join Points bezeichnet. Sie sind wohldefinierte Stellen im Programm bzw. im Programmablauf, an denen die Aspekte mit dem Nicht-Aspekt- Code koordiniert werden. An welchen Stellen diese Punkte definiert sind, hängt von der jeweiligen Implementierung der Aspektorientierten Programmiersprache ab. Das Join Point Modell ist der wichtigste Teil der Programmiersprache, da es den Rahmen der Eingriffsmöglichkeiten absteckt. Man kann Join Points auch als Knoten in einem Kontrollflussdiagramm zwischen Objekten und Methoden betrachten. Abbildung 8: Join Point Modell Um Aspekte auch quer schneiden (=crosscutting) zu können, lassen sich Join Points auf Aspekte genauso anwenden wie auf Klassen. Welche Join-Points konkret vorliegen, hängt vom verwendeten AOP-System ab. Wohl alle Systeme erlauben die Interaktion mit Methodenaufrufen andere erlauben zusätzlich das Abfangen von Feldzugriffen, Ausnahmebehandlung usw. Also funktioniert dieses Modell nach folgendem Prinzip: "Wenn Ereignis (Join Point) eintritt, dann führe Aktion(Advice) aus" 8 von 28 David Hahn & Viktor Steinwand

9 3.3 Weitere Begriffe Pointcuts Ein Pointcut ist eine Beschreibung bzw. Zusammenfassung eines oder mehrerer Join Points. Alternativ kann man ihn auch als Filter für Join Points bezeichnen. Er filtert aus allen Verfügbaren diejenigen heraus, die erfasst werden sollen. Er verwendet außer der reinen Beschreibung der zu fassenden Join Points zusätzliche Informationen, in welchem Kontext (z.b. Variablenbelegung, Parameter eines Methodenaufrufs, Name der abgefragten Variable, usw.) der Join Point im Pointcut erfasst werden soll. Er kann mit einem Namen versehen werden, um später in einem oder mehreren Advices angesprochen werden zu können, oder anonym sein und nur an der Position seiner Verwendung deklariert sein Advices Wird ein Pointcut während des Programmablaufes erreicht, bestimmt der Advice, was in diesem Fall getan werden soll. Der Advice enthält Programmcode, der ausgeführt werden soll. Der Advice bestimmt auch, an welcher Stelle eines Pointcuts eingegriffen werden soll. Diese Stellen sind unter anderem vor (before), nach (after) und anstelle (around). Je nach Implementierung kennt die Aspektorientierte Programmiersprache noch zusätzliche Stellen. Wenn ein Join Point erreicht wird, werden Advices untersucht und dabei festgestellt, welche angewendet werden sollen. Wenn mehr als ein Advice an diesem Join Point anliegt, braucht man ein Verfahren mit dem die Reihenfolge der Ausführungen der Advices bestimmt werden kann. 9 von 28 David Hahn & Viktor Steinwand

10 3.4 Entwicklungsphase OO und AOP Abbildung 9: Entwicklungsphasen in OOP und AOP Die Entwicklungsphasen in OOP und AOP [Abbildung. 9] sehen dann wie folgt aus: Bei Bedarf nach neuen Features in dem technischen Aspekten muss in der OOP an vielen Stellen eingegriffen werden und Änderungen gemacht werden. In der AOP ist es dagegen viel einfacher Änderungen durchzuführen, in dem man die Aspekte an einer zentralen Stelle abändert und diese dann in das Basisprogramm eingewebt werden. 10 von 28 David Hahn & Viktor Steinwand

11 4. Arten von AOP 4.1 Proxies und Kontexte Die.NET Plattform bietet einige mächtige Techniken, um den Programmfluss zu verändern. Mittels Kontexten lassen sich Methodenaufrufe auf beliebigen Objekten abfangen und umleiten. Kontexte stehen direkt als eigenständige Programmierschnittstelle in.net zur Verfügung und stellen eine Kapselung einer Aufrufumgebung dar. Innerhalb dieser Umgebung können Methodenaufrufe dann beliebig umgeleitet werden. Das Prinzip funktioniert folgendermaßen: Zur Kompilierzeit werden zunächst ein oder mehrere Kontexte spezifiziert. Diese implementieren die Crosscutting Concerns. Um einen Methodenaufruf auf einem bestimmten Objekt abzufangen, wird ein Objekt an den Kontext gebunden. Das Objekt ist dadurch hinter einem Proxy verborgen. Dieses führt dazu, dass nicht das ursprüngliche Objekt aufgerufen wird, sondern der Kontext. Dieser arbeitet die Crosscutting Concerns ab und und delegiert ggf. weiter an das ursprüngliche Objekt [Abbildung. 10]. Abbildung 10: Proxies und Kontexte 11 von 28 David Hahn & Viktor Steinwand

12 4.2 Webe-basierte Ansätze Die komfortabelste Weise aspektorientiert zu programmieren, ist es sicherlich auf die Hilfe eines dafür spezialisierten Compilers zurückzugreifen. Jede.NET -Anwendung wird von einem Compiler in das standardisierte CIL- Format(Common Intermediate Language) übersetzt. Webe-basierte (weaved based) AOP-Werkzeuge für.net arbeiten üblicherweise auf dieser Zwischenebene zwischen Hochsprache und Maschinencode und verbinden durch Transformationen den ursprünglichen Anwendungscode vom Basisprogramm mit dem Anwendungscode, der für die Implementation eine Aspektes benötigt wird. Dieser Prozess wird Weben(weaving) genannt [Abbildung. 11]. Abbildung 11: Webe-basierte Ansätze 12 von 28 David Hahn & Viktor Steinwand

13 5. Vorteile durch AOP 5.1 Stärkere Modularisierung Ein ganz wichtiger Vorteil der AOP ist die Zentrale Entwicklung und Wartung der benötigten Komponente, wie das aus dem Bild zu entnehmen ist [Abbildung. 12]. Es entsteht hierbei keine Code-Verstreuung und man hat weniger Coderedundanz. Außerdem hat man dann einen positiven Nebeneffekt, nämlich den kürzeren Code, der auch sauber und systemweit einheitlich umsetzt ist. Durch diese Abbildung 12: Modularisierung geschaffene Klarheit sind die unternehmensweite Richtlinien besser umsetzbar. 5.2 Klarere Trennung der Verantwortung Die aspektorientierte programmierung gewährleistet eine klarere Trennung der Verantwortung. Dabei ist der Gedanke ganz einfach: ein Modul, hat nur eine Verantwortung. Dadurch erfolgt keine Code-Vermischung und das Ergebnis ist ein verständlicher Quellcode (Geschäftslogik, Technische Details). Abbildung 13: Trennung der Verantwortung 5.3 Stärkere Wiederverwendung Bei der Aspektorientierten Programmierung entstehen lose gekoppelte Module mit denen sich das System konfigurieren lässt. Der Entwickler kann dabei verschiedene Module einweben aber auch wieder herausnehmen (z.b. Profiling). Durch diese Möglichkeit lässt sich sehr einfach eine individuelle Aspekt-Bibliothek aufbauen. Abbildung 14: Stärkere Wiederverwendung 13 von 28 David Hahn & Viktor Steinwand

14 5.4 Höhere Produktivität Durch den Einsatz von AOP entstehen einige durchaus positive Folgen für die Entwickler. Diese konzentrieren sich von nun an auf ihren Expertenbereich. Dadurch wird eine höhere Code-Qualität erreicht. Außerdem können voneinander unabhängige Module parallel entwickelt und somit ist es möglich pro Modul einen eigenen Entwicklungs- zyklus einzuführen. Abbildung 15: Höhere Produktivität 6. Anwendungen Beispiele für das Auftreten von Crosscutting Concerns, die durch Aspekte modelliert werden können, sind (neben vielen anderen): Sicherheitsüberprüfungen, Persistierung von Objekten, Synchronisation von Threads, Fehlerbehandlung, Optimierungen und optimale Ausnutzung von Ressourcen (z.b. Netzwerkbandbreite) transparentes Caching von Daten. 7. Programmbeispiele 7.1 Ein Beispiel des Loggings mit Spring.NET In diesem Beispiel wird das Logging mehrerer Methodeaufrufe demonstriert. Um die Funktionalität des Programms zu gewährleisten, müssen die im Quellcodeabschnitt dargestellten namespaces eingebunden werden. using Spring.Context; using Spring.Context.Support; using Spring.Aop.Framework; using Spring.Aop.Support; using LoggingSpring.Advices; Quellcode 1: benötigte Namespaces (Spring.NET) Die namespaces, die bereits im Spring.NET Framework enthalten sind beinhalten die Klassen für die Funktionalität der Aspektorientierten Programmierung [Quellcode 1. Zeile 1 4]. In der letzen Zeile [Quellcode 1.] wurden die selbst 14 von 28 David Hahn & Viktor Steinwand

15 implementierte Advices (Blöcke mit Anweisungen für das Logging, die vor, nach oder während des Aufrufs der Funktion/Methode ausgeführt werden) eingebunden. Das namespace LoggingSpring beinhaltet eine Klasse Logging, die über eine main- Methode verfügt. Dort wird eine AOP-Proxyinstanz (factory) mit der Klasse ServiceCommand initialisiert und somit in ein Proxyobjekt gekapselt. Das Objekt factory verfügt über eine Methode AddAdvice(Advice), die zum Hinzufügen von Advices dient. Jede einzelne Advice-Klasse implementiert Funktionen, die für das Logging zuständig sind. In diesem Beispiel sind das lediglich Ausgaben auf der Konsole [Quellcode 2. Zeilen 1-9]. Des Weiteren muss die Klasse ServiceCommand über das Interface ICommand angesprochen werden, damit die Methodenaufrufe der Klasse ServiceCommand vom Proxy abgefangen und dann verarbeitet werden können [Quellcode 2. Zeilen 11-14]. // Erstellen von AOP-Proxy, intialisiert mit der Klasse ServiceCommand // ServiceCommand wird in Proxy gekapselt ProxyFactory factory = new ProxyFactory(new ServiceCommand()); // Advices hinzufuegen factory.addadvice(new LoggingBefore()); factory.addadvice(new LoggingAfter()); factory.addadvice(new LoggingThrows()); factory.addadvice(new LoggingAround()); // Klasse ServiceCommand ueber das Interface ICommand ansprechen ICommand command = (ICommand) factory.getproxy(); command.execute(); command.foo("hallo"); Quellcode 2: Advices direkt hinzufügen (Spring.NET) Die Regular-Expressions können auch angewendet werden um nur Methoden mit passenden Namen abzufangen und zu protokollieren. In dem nachfolgenden Beispiel werden alle Methoden der Klasse ServiceCommand abgefangen, die die Buchstabenkombination Do enthalten [Quellcode 3.]. An dieser Stelle wird dann die Methode Foo(String text) [Quellcode 3. Zeile 10] nicht abgefangen, weil die Buchstabenkombination Do nicht zutrifft. Die Methode DoExecuteI(String text) wird aber problemlos abgefangen und entsprechend den angehängten Advices behandelt [Quellcode 3.]. ProxyFactory factory = new ProxyFactory(new ServiceCommand()); factory.addadvisor(new DefaultPointcutAdvisor, new SdkRegularExpressionMethodPointcut("Do"), new LoggingAround() )); ICommand command = (ICommand) factory.getproxy(); command.doexecute("doexecute3"); //der pointcut trifft nicht zu (der Methodenname beinhaltet die Buchstaben 'Do' nicht) command.foo("hallo3"); Quellcode 3: Advices direkt hinzufügen mit Regular Expression (Spring.NET) 15 von 28 David Hahn & Viktor Steinwand

16 Unter Anderem ist es möglich die Einstellungen aus der Konfigurationsdatei zu lesen und zu verarbeiten. Hier ist es nicht notwendig ein Proxy-Objekt anzulegen, da so ein Objekt bereits in der Konfigurationsdatei beschrieben ist [Quellcode 4.]. IApplicationContext ctx = ContextRegistry.GetContext(); ICommand command = (ICommand) ctx["myserviceobject"]; command.foo("gelesen aus Config-Datei"); command.doexecute("busines Logic..."); Quellcode 4: Verwenden einer Konfigurationsdatei (Spring.NET) Bei der Konfigurationsdatei handelt es sich um eine XML-Datei [Quellcode 5.]. Diese beinhaltet Objekte die für das Logging zuständig sind und auch Objekte für die Klasse ServiceCommand, sowie ein Proxy in dem ebenfalls die Klasse ServiceCommand gekapselt und dann über das Interface command vom Typ ICommand angesprochen wird. 16 von 28 David Hahn & Viktor Steinwand

17 <?xml version="1.0" encoding="utf-8"?> <configuration> <configsections> <sectiongroup name="spring"> <section name="context" type="spring.context.support.contexthandler, Spring.Core" /> <section name="objects" type="spring.context.support.defaultsectionhandler, Spring.Core" /> </sectiongroup> </configsections> <spring> <context> <resource uri="config://spring/objects" /> </context> <objects xmlns=" <description>ein Beispiel zur Demonstration der Funktionsweise von AOP</description> <object id="throwsadvice" type="loggingspring.advices.loggingthrows" /> <object id="loggingaround" type="loggingspring.advices.loggingaround" /> <object id="loggingafter" type="loggingspring.advices.loggingafter" /> <object id="myserviceobject" type="spring.aop.framework.proxyfactoryobject"> <property name="target"> <object id="myserviceobjecttarget" type="loggingspring.advices.servicecommand" /> </property> <property name="interceptornames"> <list> <value>throwsadvice</value> <value>loggingaround</value> <value>loggingafter</value> </list> </property> </object> </objects> </spring> </configuration> Quellcode 5: Beispiel einer Konfigurationsdatei (Spring.NET) Es ist auch möglich Regular Expressions aus der Konfigurationsdatei zu verwenden [Quellcode 6.]. 17 von 28 David Hahn & Viktor Steinwand

18 <object id="loggingaround" type="spring.aop.support.regularexpressionmethodpointcutadvisor"> <property name="pattern" value="do" /> <property name="advice"> <object type="loggingspring.advices.loggingaround" /> </property> </object> Quellcode 6: Regular Expressions in einer Konfigurationsdatei (Spring.NET) Das Interface ICommand verfügt lediglich über eine Liste der Methoden der Klasse ServiceCommand, die dann auch tatsächlich abgefangen werden können. Also werden die Methoden der zu diesem Interface angehängten Klasse ServiceCommand über das Interface angesprochen. [Quellcode 7.] public interface ICommand void Execute(); void DoExecute(string text); string Foo(string text); Quellcode 7: Interface ICommand (Spring.NET) Die Klasse ServiceCommand implementiert also diese Methoden. Bei dieser Klasse, handelt es sich um eine Klasse deren Methoden überwacht und geloggt werden. Hier können sich die Entwickler auf ihren Expertenbereich konzentrieren, ohne dass sie an der Stelle an das Logging denken müssen [Quellcode 8.]. public class ServiceCommand : ICommand // Beispielmethoden public void Execute() public void DoExecute(string text) public string Foo(string text) Quellcode 8: Klasse ServiceCommand (Spring.NET) Wie schon der Name der Klasse (LoggingBefore) besagt, ist diese Klasse für das Abfangen der Methode vor deren Ausführung zuständig. In der Methode Before( ) kann man beliebige Protokollierungen und Ausgaben implementieren, die für das Logging verantwortlich sind. Man kann den Methodennamen, das Zielobjekt und die übergebenen Parameter der zu überwachenden Methode festhalten [Quellcode 9.]. 18 von 28 David Hahn & Viktor Steinwand

19 // Logging vor dem Aufruf der Methode public class LoggingBefore : IMethodBeforeAdvice public void Before(MethodInfo method, object[] args, object target) Console.WriteLine("\nLoggingBefore"); Console.WriteLine("[Before] Abgefangene Methode: " + method.name); Console.WriteLine("[Before] Das Zielobjekt: " + target); Console.WriteLine("[Before] Die Parameter: "); if(args!= null) int i = 1; foreach (object arg in args) Console.WriteLine("\t\t"+i+"): " + arg); i++; Quellcode 9: Klasse LoggingBefore (Spring.NET) Die Advices LoggingAfter, LoggingAround und LoggingThrows sind auf eine ähnliche Art und Weise implementiert, mit dem Unterschied, dass diese an anderen Zeitpunkten eingreifen. Beim LoggingAfter wird die Methode beim Verlassen abgefangen, dort kann man zusätzlich zu den Möglichkeiten des LoggingBefore auch die Rückgabewerte protokollieren. [Quellcode 10.] // Logging nach dem Aufruf der Methode public class LoggingAfter : IAfterReturningAdvice public void AfterReturning(object returnvalue, MethodInfo method, object[] args, object target) Console.WriteLine("\nLoggingAfter"); Console.WriteLine( "[After] Abgefangener Aufruf der Methode: " + method.name); Console.WriteLine("[After] Das Zielobjekt: " + target); Console.WriteLine("[After] Die Parameter: "); if(args!= null) int i = 1; foreach (object arg in args) Console.WriteLine("\t\t"+i+"): " + arg); i++; Console.Out.WriteLine( "\t\t[after] Rueckgabewert: " + returnvalue); Quellcode 10: Klasse LoggingAfter (Spring.NET) 19 von 28 David Hahn & Viktor Steinwand

20 Etwas anders funktioniert das Advice LoggingAround, hier wird die Methode während des Aufrufes abgefangen. So hat man dort die Möglichkeit im Gegensatz zu den zuvor genannten Advices die abgefangene Methode nur dann auszuführen, wenn bestimmte Bedingungen erfüllt werden [Quellcode 11.]. // Logging waehrend des Aufrufs der Methode public class LoggingAround : IMethodInterceptor public object Invoke(IMethodInvocation invocation) Console.WriteLine("\nLoggingAround"); Console.WriteLine("[Around] Abgefangener Aufruf."); // hier kann man auf Bedingungen überprüfen // und ggf. den Aufruf gar nicht erst erlauben object returnvalue = invocation.proceed(); Console.WriteLine("[Around], Rueckgabe: " + returnvalue); return returnvalue; Quellcode 11: Klasse LoggingAfter (Spring.NET) Wie schon der Name des Advices LoggingThrows verrät, werden mit deren Hilfe die fehlerhaften Aufrufe abgefangen und somit hat der Programmierer die Möglichkeit an dieser Stelle die möglichen Fehlerfälle zu protokollieren. [Quellcode 12.] // Logging vor dem Werfen einer Exception public class LoggingThrows : IThrowsAdvice public void AfterThrowing(Exception ex) Console.WriteLine("\nLoggingThrows"); Console.WriteLine("Diese Exception wurde geworfen: " + ex); Quellcode 12: Klasse LoggingThrows (Spring.NET) 20 von 28 David Hahn & Viktor Steinwand

21 7.2 Ein Beispiel des Loggings mit Aspect# In diesem Beispiel wird das Logging mehrerer Methodeaufrufe einer Klasse sowie einer Klasse gekoppelt mit einem Interface demonstriert. Wie auch im oberen Beispiel, ist es hier notwendig, um die Funktionalität des Programms zu gewährleisten, die namespaces einzubeziehen. using AspectSharp; using AspectSharp.Builder; using Logging.Model; Quellcode 13: benötigte Namespaces (Aspect#) In der letzten Zeile wurde das namespace mit den zu überwachten Klassen und Interceptors (Abfänger), die selbst implementiert werden müssen, eingebunden. Die restlichen namespaces sind bereits im Aspect# enthalten und sorgen für die Funktionalität der Aspektorientierten Programmierung. [Quellcode 13.] Hier ist man aber im Vergleich zu Spring.NET auf eine Konfigurationsdatei angewiesen. Nur in dieser Datei können die Pointcuts definiert werden. [Quellcode 14.] <?xml version="1.0" encoding="utf-8"?> <configuration> <!-- General Config --> <configsections> <section name="aspectsharp" type="aspectsharp.builder.sectionhandler.aspectsharpconfigurationhandler, AspectSharp" /> </configsections> <!-- AspectSharp settings --> <aspectsharp> <configuration> <![CDATA[ import Logging.Model in Logging interceptors [ "logger" : LogInterceptor ] aspect InterfaceLogger for [ assignablefrom(ieininterface) ] pointcut method(string *(string, *)) advice("logger") end end aspect ClassLogger for EineKlasse pointcut method(*) advice(loginterceptor) end end ]]> </configuration> </aspectsharp> </configuration> Quellcode 14: Konfigurationsdatei (Aspect#) 21 von 28 David Hahn & Viktor Steinwand

22 Man kann Aspekte für Interfaces aber auch für Klassen erzeugen, um dort dann die Pointcuts zu definieren. Diese wiederum entscheiden, welche Methoden nun mittels Interceptors abgefangen werden sollen und welche nicht. Man kann zwar keine Regular-Expressions an dieser Stelle verwenden, aber dafür gibt es ein anderes Verfahren welches auch seine Stärken hat. In Aspect# kann man anhand der Datentypen der übergebenen Parameter definieren, welche Methoden abgefangen werden sollen. Im nachfolgenden Beispiel [Quellcode 14. Zeile 17 21] werden alle Methoden, die über das Interface IEinInterface angesprochen werden können, nicht geloggt. Ausschließlich Methoden, die die ein String zurückliefern und den ersten Parameter auch vom Typ String haben können geloggt werden. In der main-methode wird zuerst die Konfiguration eingelesen und dann eine Engine basierend auf der oben beschriebenen Konfiguration erstellt. [Quellcode 15.] //Einlesen der Konfiguration aus der Config-Datei AppDomainConfigurationBuilder builder = new AppDomainConfigurationBuilder(); //Erstellen der AspectEngine basierend auf der Konfiguration _engine = builder.build(); Quellcode 15: Erstellen von Engine aus der Konfigurationsdatei (Aspect#) Auch bei Aspect# können Methoden abgefangen werden, die entweder über ein Interface oder über eine virtuelle Methode angesprochen werden, geloggt. Die Methoden, die nicht virtuell sind können nicht abgefangen werden. Damit das Logging funktioniert, muss die zu protokollierende Klasse zuerst in die Engine gekapselt oder anders genannt gewrappt werden. [Quellcode 16 Zeilen 1-2] Die Methode EineMethode(int) [Quellcode 16. Zeile 5] kann nicht abgefangen werden, da es sich hierbei um keine virtuelle Methode handelt. Das Abfangen und Behandeln der restlichen aufgerufenen Methoden ist möglich, da diese virtuell sind. [Quellcode 17.] // Klasse Wrappen, d.h. kapseln EineKlasse ek = _engine.wrapclass(typeof(eineklasse)) as EineKlasse; // Wird nicht abgefangen ek.einemethode(5); // Wird abgefagen und geloggt ek.einevirtuellemethode(); Console.WriteLine(" "); ek.anderevirtuellemethode(77); Quellcode 16: Logging der Methodenaufrufe einer Klasse in (Aspect#) 22 von 28 David Hahn & Viktor Steinwand

23 Da mit Aspect# nur virtuelle Methoden abgefangen werden können, kann man hier die Aufrufe der normalen Methoden über virtuelle Methoden realisieren, so dass diese dann auch abgefangen werden. Diese delegieren in diesem Zusammenhang nur als Weiterleitung. [Quellcode 17.] // wird nicht abgefangen public int EineMethode(int zahl) // nur virtual Methoden koennen abgefangen werden public virtual int EineVirtuelleMethode() return EineMethode(10); // nur virtual Methoden koennen abgefangen werden public virtual int AndereVirtuelleMethode(int zahl) return EineMethode(zahl); Quellcode 17: Klasse EineKlasse (Aspect#) Auf eine ähnliche Art und Weise funktioniert das auch für Interfaces. Der Unterschied ist aber, dass nur Methoden, die über dieses Interface erreichbar sind, protokolliert werden können. Auch hier muss die Klasse, die mit dem Interface kompatibel ist in eine Engine gekapselt werden [Quellcode 18. Zeile 1-3]. Im folgenden Beispiel können nur Methoden, die ein String zurückgeben und als ersten Parameter einen String erwarten abgefangen werden.[quellcode 14. Zeile 17-21] Dabei spielen für die Auswahl der zu protokollierenden Methode die übrigen übergebenen Parameter keine Rolle mehr. // Klasse, die mit dem Interface kompatibel ist wrappen IEinInterface iei = _engine.wrapinterface(typeof(ieininterface), new Person()) as IEinInterface; // pointcut method(string *(string, *)) // so werden nur Methoden, die // 1. ein string zurueckgeben // 2. und ein string als ersten Parameter erwarten (die restlichen sind egal) // geloggt iei.alter(24, "David"); Console.WriteLine(" "); iei.person("steinwand", "Viktor"); Console.WriteLine(" "); iei.gehalt("hahn", 0); Quellcode 18: Logging der Methodenaufrufe über ein Interface (Aspect#) Das Interface IEinInterface beschreibt nur Methoden, die in der Klasse Person implementiert sind und abgefangen werden sollen. Der tatsächlich auszuführende Code befindet sich in der Klasse Person. [Quellcode 19.] [Quellcode 20.] 23 von 28 David Hahn & Viktor Steinwand

24 public interface IEinInterface string alter(int alter, string name); string person(string name, string vorname); string gehalt(string name, int gehalt); Quellcode 19: Interface IEinInterface (Aspect#) public string alter(int alter, string name) public string person(string name, string vorname) public string gehalt(string name, int gehalt) Quellcode 20: Klasse Person (Aspect#) Für das Abfangen dieser Methoden ist die Klasse LogInterceptor (Interceptor = Abfänger) zuständig. In Aspect# wird nur das Advice Around (während der Ausführung) verwendet. Hier kann man den Methodennamen, die Parameter und den Rückgabewert ermitteln und protokollieren. Der Rückgabewert steht jedoch erst nach der Ausführung der Methode für die Protokollierung bereit. In diesem Beispiel werden die Ausgaben zur Demonstrationszwecken auf die Konsole gegeben. Die Ausführung der abgefangenen Methode kann man verhindern, falls bestimmte Bedingungen nicht erfüllt werden konnten. 24 von 28 David Hahn & Viktor Steinwand

25 // Abfangen des Methodenaufrufs public class LogInterceptor : IMethodInterceptor public LogInterceptor() public object Invoke(IMethodInvocation invocation) LogMethod(invocation.Method); LogArguments(invocation.Arguments); object result = invocation.proceed(); LogReturn(result); return result; private void LogMethod(MethodBase method) Console.WriteLine("Methode: 0", method.name); private void LogReturn(object result) Console.WriteLine("Rueckgabewert: 0", result); private void LogArguments(object[] arguments) for (int i = 0; i < arguments.length; i++) Console.WriteLine("Argument Index: 0. Value: 1", i, arguments[i]); Quellcode 21: Klasse LogInterceptor (Aspect#) 8. Entwicklungsstand Die aspektorientierte Programmierung steckt heute noch in den Kinderschuhen. Außerdem ist strittig, ob und wie aspektorientierte Programmierung auf Objekt-Ebene zu realisieren ist. Eine Lösung könnte die Einführung einer Methodeneigenschaft "controllable" oder "aspect" sein, welche als Joint-Point verwendbare Methoden kennzeichnet, das polymorphe Methoden kennzeichnet. Zahlreiche bestimmte Erfahrungen müssen auch erst noch gemacht werden. Klassische Entwurfsmuster, Refaktorisierungen und Fallstricke der Objektorientierung waren schließlich auch nicht von Anfang an bekannt. Bis sich die aspektorientierte Programmierung zu einem dominierenden Programmierparadigma wie heute die objektorientierte Programmierung entwickelt hat, dürften noch einige Jahre vergehen. Man kann davon ausgehen, dass sich auf der Basis der objektorientierten Programmiersprachen Java und C# aspektorientierte Programmiersprachen entwickeln werden. 25 von 28 David Hahn & Viktor Steinwand

26 Diese werden den Programmierern ermöglichen, die Aspektorientierung zu erkunden, aspektorientierte Programmiermuster zu entwerfen und schließlich zur Entwicklung ausgereifter aspektorientierter Sprachen und Laufzeitumgebungen führen. 9. Fazit Als Fazit muss man sagen, dass aspektorientierte Programmierung ein mächtiges Werkzeug für den Entwickler-Werkzeugkoffer ist. AOP könnte in der Zukunft zunehmend, sowohl in der kommerzielle Nutzung als auch im privaten Bereich, an Bedeutung gewinnen. Mit Aspect# und Spring.NET stehen heute schon zwei mächtige Entwicklungswerkzeuge für.net zu Verfügung. 10. Quellen (Aspect#) (Spring.NET) (Suchwort: Aspektorientierte Programmierung) (Post-Objekt-Orientierte Ansätze zur Softwareentwicklung) wwwse.fhs-hagenberg.ac.at (AOP.NET) users.informatik.haw-hamburg.de/~raasch/akot-aop.pdf 26 von 28 David Hahn & Viktor Steinwand

27 11. Abbildungsverzeichnis Abbildung 1: Geschäftslogik...4 Abbildung 2: Crosscutting Concerns...4 Abbildung 3: Quellcode des Apacheservers...5 Abbildung 4: Code, der in Tomcat für das Logging benutzt wird...6 Abbildung 5: Code Tangling...6 Abbildung 6: Code Scattering...6 Abbildung 7: Vorgehen beim AOP...7 Abbildung 8: Join Point Modell...8 Abbildung 9: Entwicklungsphasen in OOP und AOP...10 Abbildung 10: Proxies und Kontexte...11 Abbildung 11: Webe-basierte Ansätze...12 Abbildung 12: Modularisierung...13 Abbildung 13: Trennung der Verantwortung...13 Abbildung 14: Stärkere Wiederverwendung...13 Abbildung 15: Höhere Produktivität von 28 David Hahn & Viktor Steinwand

28 12. Quellcodeverzeichnis Quellcode 1: benötigte Namespaces (Spring.NET)...14 Quellcode 2: Advices direkt hinzufügen (Spring.NET)...15 Quellcode 3: Advices direkt hinzufügen mit Regular Expression (Spring.NET)...15 Quellcode 4: Verwenden einer Konfigurationsdatei (Spring.NET)...16 Quellcode 5: Beispiel einer Konfigurationsdatei (Spring.NET)...17 Quellcode 6: Regular Expressions in einer Konfigurationsdatei (Spring.NET)...18 Quellcode 7: Interface ICommand (Spring.NET)...18 Quellcode 8: Klasse ServiceCommand (Spring.NET)...18 Quellcode 9: Klasse LoggingBefore (Spring.NET)...19 Quellcode 10: Klasse LoggingAfter (Spring.NET)...19 Quellcode 11: Klasse LoggingAfter (Spring.NET)...20 Quellcode 12: Klasse LoggingThrows (Spring.NET)...20 Quellcode 13: benötigte Namespaces (Aspect#)...21 Quellcode 14: Konfigurationsdatei (Aspect#)...21 Quellcode 15: Erstellen von Engine aus der Konfigurationsdatei (Aspect#)...22 Quellcode 16: Logging der Methodenaufrufe einer Klasse in (Aspect#)...22 Quellcode 17: Klasse EineKlasse (Aspect#)...23 Quellcode 18: Logging der Methodenaufrufe über ein Interface (Aspect#)...23 Quellcode 19: Interface IEinInterface (Aspect#)...24 Quellcode 20: Klasse Person (Aspect#)...24 Quellcode 21: Klasse LogInterceptor (Aspect#) von 28 David Hahn & Viktor Steinwand