Ideen der Aspektorientierung in Prolog

Transkript

1 Universität Rostock, Fakultät für Informatik und Elektrotechnik, Institut für Informatik Diplomarbeit Ideen der Aspektorientierung in Prolog vorgelegt von Guido Wachsmuth Betreuer: Gutachter: Prof. Dr. rer. nat. Dr.-Ing. habil. Günter Riedewald Dipl. Inf. Wolfgang Lohmann Prof. Dr. rer. nat. Dr.-Ing. habil. Günter Riedewald Prof. Dr.-Ing. habil. Peter Forbrig

2

3 Zusammenfassung Unter Verwendung herkömmlicher Modularisierungskonzepte moderner Programmiersprachen lassen sich die Implementationen gewisser Eigenschaften einer Software nicht innerhalb eines Moduls separat beschreiben. Stattdessen neigen solche Eigenschaften dazu, modulare Implementationen anderer Eigenschaften mit ihrer Implementation zu überschneiden. Dies erschwert Verständnis, Wartbarkeit, Erweiterbarkeit und Wiederverwendbarkeit der erstellten Software-Komponenten. Die aspektorientierte Programmierung addressiert dieses Problem. Sie führt mit Aspekten ein Modularisierungskonzept für die Implementation solcher Crosscutting Concerns ein. Die vorliegende Arbeit untersucht die Übertragung dieser Ideen auf Prolog. Es wird gezeigt, dass Crosscutting Concerns auch in der Programmierung mit Prolog auftreten und sich diese mit Hilfe von Prädikaten und Klauseln nicht modular implementieren lassen. Anschließend werden Lösungsansätze wie Port-Annotationen und die Methode des Stepwise Enhancements, welche abseits der aspektorientierten Programmierung für dieses Problem in Prolog existieren, vorgestellt, mit Ideen der aspektorientierten Programmierung verglichen und bewertet. Darauf aufbauend wird ein Modell zur aspektorientierten Programmierung in Prolog entwickelt. Unter Verwendung dieses Modells werden Programmiertechniken generisch beschrieben. Ferner wird gezeigt, wie die aspektorientierte Entwicklung von Sprachprozessoren generisch unterstützt werden kann. Abstract Some software properties can not be implemented as separated modules using common concepts of modern programming languages. Instead implementations of those properties tend to crosscut modular implementations of other properties. This decreases understanding, maintainibility, extensibility, and reusability of software components. Aspect-oriented programming overcomes this problem by introducing aspects as a new concept to implement these crosscutting concerns in isolation. This work investigates the adaption of those ideas to Prolog. It is shown that crosscutting concerns occur in Prolog programs and can not be modularised by the use of predicates and clauses. Existing solutions addressing this problem for Prolog programs like port annotations and the method of stepwise enhancement are presented, compared to aspect-oriented concepts, and evaluated subsequently. Based on those reflections a model for aspect-oriented programming in Prolog is developed. The model is used to formalise programming techniques in a generic manner. Furthermore a generic approach to assist aspect-oriented developing of language processors is presented. CR-Klassifikation: D.1.6, D.2.3, D.2.7, D.2.13, D.3.3 Schlüsselwörter: Prolog, logische Programmierung, aspektorientierte Programmierung, Programmsynthese, Erweiterbarkeit, Wiederverwendbarkeit, Wartbarkeit, Design by Contract, Stepwise Enhancement, Programmiertechniken, Sprachprozessoren

4 Inhaltsverzeichnis 1 Einleitung Motivation Zielstellung Vorgehen und Aufbau Grundlagen der Aspektorientierung Ausgangslage Software-Entwicklungsprozess Separation of Concerns Hierarchische Modularisierung Crosscutting Concerns Aspektorientierte Programmierung Komponenten und Aspekte Webevorgang Joinpoint-Modelle Aspektorientierung aus objektorientierter Sicht Modularisierungskonzepte Typische Anwendungen AspectJ Anliegen Dynamisches Joinpoint-Modell Übersetzung Method-Call Interception Anliegen Dynamisches Joinpoint-Modell Übersetzung Aspektorientierung aus Prolog-Sicht Modularisierungskonzepte Typische Anwendungen Stepwise Enhancement Methodik Programmkomponenten Komposition von Komponenten Aspektorientierung

5 Inhaltsverzeichnis Verwandte Konzepte Port-Annotationen Portmodell Annotationen Umsetzung Aspektorientierung Verwandte Konzepte Statisches Joinpoint-Modell Joinpoints Erweitertes Portmodell Boxen und Joinpoints Pointcut-Beschreibungen Erfassung von Joinpoints Kontext Fixpunkt-Semantik Advices Port-Advices Around-Advices Term-Advices Reihenfolge von Advices Aspekte Einfache Aspekte Abhängigkeiten zwischen Aspekten Generische Aspekte Anwendungen Design by Contract Spezifikation durch dynamische Tests Spezifikation von Sortierprädikaten Techniken Techniken und Aspekte Build- und Calculate-Technik Akkumulator-Techniken Differenzstrukturen Kontextpropagierung Sprachprozessoren Implementation von Sprachprozessoren in Prolog Parser Unparser

6 Inhaltsverzeichnis 7 Abschließende Betrachtungen Ergebnisse der Arbeit Weiterführende Arbeiten Konzeptuelle Weiterentwicklung Tool-Support Anwendungen Literaturverzeichnis 97 A Implementation 106 A.1 Pointcut-Beschreibungen A.1.1 Kontext A.1.2 Fixpunkt-Algorithmus A.2 Advices A.2.1 Port-Advices A.2.2 Term-Advices A.3 Aspekte A.4 Weber A.4.1 Dateien A.4.2 Programme A.4.3 Klauseln A.4.4 Ziele A.4.5 Port-Advices A.4.6 Term-Advices A.4.7 Vereinfachungen A.5 Hilfsprädikate A.5.1 Subsumption A.5.2 Mehrere Lösungen A.5.3 Ein- und Ausgabe A.5.4 Variablennamen

7 1 Einleitung 1.1 Motivation Das Paradigma der aspektorientierten Programmierung hat seit der Präsentation der grundsätzlichen Ideen und Ziele [45] eine weite Akzeptanz gefunden und ist heute Gegenstand weitgehender Forschungen [5, 63, 25]. Ein Großteil dieser Forschung bezieht sich nach wie vor auf eine Sicht der Aspektorientierung als Erweiterung für objektorientierte Programmiersprachen. Seit ihrer Entstehung beeinflusst die Idee der Aspektorientierung jedoch auch andere Paradigmen [17, 56], darunter auch das deklarative Paradigma [54]. Prolog stellt eine Ausprägung dieses Paradigmas da. Dabei dient die Sprache auch der Entwicklung größerer Anwendungen wie Prototypen verschiedener Art [12, 75, 10, 57], Expertensystemen [15, 32, 27, 80] oder wissenschaftlichen Modellierungen und Simulationen [2, 79]. Eine Strukturierung und Modularisierung solcher Anwendungen trägt entscheidend zu deren Verständlichkeit, Wartbarkeit und Wiederverwendbarkeit bei. Darüber hinaus stellt gerade die Entwicklung von Prototypen hohe Anforderungen an die Erweiterbarkeit von Implementationen. Aspektorientierte Ansätze adressieren genau diese Anforderungen. Hierbei ergeben sich für objektorientierte Anwendungen ähnlicher Dimensionen die angestrebten Vorteile [45, 44, 31]. Konkrete Realisierungen für deklarative Beschreibungsformalismen [49, 39] zeigen, dass diese Vorteile durch eine Übertragung aspektorientierter Ideen auch im deklarativen Paradigma zum Tragen kommen. Des Weiteren existiert mit der prozeduralen Semantik Prologs ein direkter Bezug zu prozeduralen und objektorientierten Programmiersprachen, welcher bei einer Übertragung existenter aspektorientierter Ansätze ausgenutzt werden kann. 1.2 Zielstellung Die vorausgehenden Überlegungen zeigen, dass eine Übertragung aspektorientierter Ideen auf Prolog grundsätzlich möglich und mit den klassischen Vorteilen der Aspektorientierung verbunden sein könnte. Ziel dieser Arbeit ist es deshalb zunächst, die tatsächliche Relevanz aspektorientierter Ansätze für die Programmierung in Prolog aufzuzeigen. Filman und Friedman als prominente Vertreter der AOP-Community bestreiten in [26] eben diese Relevanz: Rule-based systems like [...] Prolog are programming with purely dynamically quantified statements. [...] If we all programmed with rules, we wouldn t have AOP discussions. We would just talk about how rules that expressed concerns X, Y, and Z 1

8 1 Einleitung could be added to the original system, with some mention of the tricks involved in getting those rules to run in the right order and to communicate with each other. Vor der Diskussion zur Übertragung aspektorientierter Ideen auf Prolog oder der Entwicklung neuer Ansätze gilt es daher, diese Aussage zu widerlegen. Es wird daher gezeigt, dass die Problematik der fehlenden Modularisierbarkeit von Crosscutting Concerns auch in Prolog existiert. Des Weiteren wird nachgewiesen, dass konkrete Anwendungen von dieser Problematik betroffen sind, Aspektorientierung diese auch in Prolog beheben kann und so bei der Entwicklung konkreter Anwendungen die Vorteile der Aspektorientierung zum Tragen kommen. Im nächsten Schritt ist zu prüfen, inwiefern aspektorientierte Ansätze für Prolog bereits existieren. Dies beinhaltet auch die Untersuchung von Methoden zur Programmentwicklung in Prolog auf eventuell inhärente aspektorientierte Ideen. Ziel der Arbeit ist dann die Entwicklung eines eigenen Ansatzes zur Aspektorientierung in Prolog. Anhand von Anwendungsbeispielen wird gezeigt, dass durch diesen Ansatz konkrete Anwendungen von den Vorteilen der Aspektorientierung profitieren. 1.3 Vorgehen und Aufbau Im Anschluss an dieses Einleitungskapitel widmet sich Kapitel 2 den Grundlagen der Aspektorientierung. Aufbauend auf einer kurzen Darstellung verschiedener Anforderungen an den Software-Entwicklungsprozess werden die grundlegenden aspektorientierten Konzepte zur Erfüllung dieser Anforderungen erläutert. Dabei werden sowohl Begriffe als auch die verschiedenen Bestandteile einer aspektorientierten Programmiersprache berücksichtigt. Da das Paradigma der aspektorientierten Programmierung vor allem von objektorientierten Ansätzen geprägt ist, wird dieses in Kapitel 3 aus objektorientierter Sicht betrachtet. Den Ausgangspunkt bildet eine Darstellung objektorientierter Modularisierungskonzepte. Daraufhin werden Anwendungsfälle, welche sich für gewöhnlich nicht mit Hilfe dieser Konzepte modularisieren lassen, erläutert und klassifiziert. Den Abschluss des Kapitels bilden die Beschreibungen von AspectJ und der Method-Call Interception. Beide Ansätze beschreiben die aspektorientierte Erweiterung objektorientierter Programmiersprachen. AspectJ bezieht sich dabei nur auf die Programmiersprache Java und hat die Diskussion um Aspektorientierung und dessen Begriffe entscheidend geprägt. Die Method-Call Interception zeigt, dass sich eine beliebige objektorientierte Programmiersprache durch die Einführung eines einzigen neuen Sprachkonstrukts um ein Mittel zur aspektorientierten Programmierung erweitern lässt. Das anschließende Kapitel 4 enthält eine analoge Betrachtung des aspektorientierten Paradigmas aus der Sicht von Prolog. Auch hier werden zunächst Konzepte zur Modularisierung präsentiert. Es wird untersucht, inwiefern sich gewisse Anwendungsfälle nicht durch diese Konzepte modularisieren lassen. Dabei liefern einige Anwendungsfälle aus der objektorientierten Betrachtung nützliche Hinweise. Im Anschluss werden mit der Methodik des Stepwise Enhancements und den Port-Annotationen zwei Konzepte logischer Programmierung betrachtet, welche einerseits einen Bezug zu diesen Anwendungsfällen 2

9 1.3 Vorgehen und Aufbau und andererseits aspektorientierte Lösungsansätze zur Modularisierung aufweisen. Dies ist besonders interessant, da beiden Ansätzen die Idee der Aspektorientierung nicht bekannt ist. Aufbauend auf den vorhergehenden Darstellungen wird in Kapitel 5 ein Modell zur aspektorientierten Programmierung in Prolog schrittweise vorgestellt. Das Modell orientiert sich dabei an den Ideen AspectJs, der Port-Annotationen und des Stepwise Enhancements. Im folgenden Kapitel 6 werden dann verschiedene Anwendungen aspektorientiert entwickelt. Zunächst werden aspektorientierte Beschreibungsmöglichkeiten von Spezifikationen logischer Prädikate beschrieben. Anschließend werden Implementationen der Techniken des Stepwise Enhancements als generische Aspekte vorgestellt sowie deren Anwendung an typischen Einführungsbeispielen aus der Literatur zum Stepwise Enhancement erläutert. Abschließend wird gezeigt, wie sich diese Techniken zur aspektorientierten Implementation von Sprachprozessoren verwenden lassen. Kapitel 7 fasst die Ergebnisse der Arbeit zusammen und gibt einen Ausblick auf weiterführende Themen. 3

10 2 Grundlagen der Aspektorientierung In diesem Kapitel werden zunächst die Ursprünge der Aspektorientierung und ihre Grundlagen vorgestellt. Dazu werden der Prozess der Software-Entwicklung und die Rolle der Modularisierung von Software-Systemen kurz analysiert sowie das Problem der Crosscutting Concerns identifiziert. Anschließend wird gezeigt, wie die Aspektorientierung dieses Problem zu lösen versucht. Dabei werden grundlegende Begriffe und Verfahrensweisen allgemein erläutert. Die folgenden Kapitel 3 und 4 enthalten dann spezifische Betrachtungen aus Sicht der objektorientierten Programmierung bzw. aus der Programmierung in Prolog. 2.1 Ausgangslage Software-Entwicklungsprozess Mit der steigenden Komplexität von Software-Systemen wächst auch die Komplexität der Entwicklung solcher Systeme. Dies führt zu einem enormen Bedarf an Ressourcen. Wissenschaftliche Fundierungen des Software-Entwicklungsprozesses versuchen daher, die Komplexität von Software-Systemen und deren Entwicklung beherrschbar zu halten und somit den Bedarf an Ressourcen zu kontrollieren [7]. Einen zentralen Punkt bildet dabei die Strukturierung. Davon ist zunächst den Entwicklungsprozess selbst betroffen. Verschiedene Modelle unterscheiden hier Phasen der Anforderungsanalyse, der Spezifikation des zu entwickelnden Systems, des Systementwurfs, der Implementation, des Tests und der Verwendung des Systems. Durch eine Strukturierung des Systems kann dessen Komplexität übersichtlich gehalten werden. Ein wesentliches Ziel ist es hierbei, auf allen Stufen der System-Entwicklung ein besseres Verständnis des Systems und seiner Umsetzung zu erhalten. Aus diesem besseren Verständnis heraus ergeben sich dann weitere Vorteile. So kann es den Aufwand für die Wartung erheblich reduzieren. Umgekehrt kann ein fehlerhaftes Verständnis die Wartung eines Systems unmöglich machen. Ein strukturiertes und wohlverstandenes System ist überdies leichter erweiterbar, was hilft, eine vollständige Neuentwicklung bei veränderten Anforderungen zu vermeiden. Die Wiederverwendbarkeit von Teilen des Systems spielt eine weitere wichtige Rolle in der Kontrolle von Ressourcen. Fehlende Strukturierung und ein unvollständiges Verständnis des Systems behindern diese ebenfalls erheblich. 4

11 2.1 Ausgangslage Separation of Concerns Die Strukturierung eines Systems wird neben der Abstraktion durch eine weitere kognitive Fähigkeit des Menschen maßgeblich unterstützt. Die Fokussierung auf einen Teil einer Gesamtheit ermöglicht es, diesen isoliert zu betrachten und Erkenntnisse über ihn zu sammeln [23]. Dabei wird die Einbettung in die Gesamtheit zwar berücksichtigt, die Gesamtheit selbst aber weitestgehend ausgeblendet. Diese Fähigkeit gestattet es, komplexe Probleme und Strukturen aufzubrechen und somit zu beherrschen. Sie durchzieht sämtliche Phasen des Software-Entwicklungsprozesses. So lassen sich bestimmte Anforderungen an ein System, Spezifikationsfragmente, Teile eines Entwurfs oder einer Implementation oder auch gewisse Testfälle isoliert betrachten. Ein solcher isoliert betrachteter Teil bildet ein Concern. Definition 1 (Concern) Ein Concern ist ein Teil einer Anforderung, einer Spezifikation, eines Entwurfs, einer Implementation oder eines Tests, welches im Interesse oder Fokus einer Betrachtung liegt. Um die im vorherigen Abschnitt aufgeführten Vorteile eines strukturierten Systems zu erreichen, muss in den einzelnen Phasen des Entwicklungsprozess eine Trennung identifizierter Concerns erfolgen (Separation of Concerns) [23]. Je besser diese Trennung gelingt und je weniger sich verschiedene Concerns überlappen, desto eher lassen sich die angestrebten Vorteile erzielen [72]. Verschiedene Software-Entwicklungsmethoden unterstützen daher die Trennung von Concerns. Als besonders kritisch erweisen sich dabei die Phasen des Entwurfs und der Implementation. Die Wahl einer Entwurfsmethode und einer Programmiersprache beeinflusst, ob Concerns, welche in den vorherigen Phasen der Anforderungsanalyse und der Spezifikation separat betrachtet werden konnten, auch im Entwurf und in der Implementation getrennt voneinander umsetzbar sind Hierarchische Modularisierung Für die Trennung von Concerns während des Entwurfs oder der Implementation sind die Modularisierungskonzepte der verwendeten Entwurfsmethoden bzw. Programmiersprachen entscheidend. In Abschnitt 3.1 werden objektorientierte Programmiersprachen auf solche Konzepte hin untersucht. Abschnitt 4.1 überträgt diese Überlegungen auf Prolog. An dieser Stelle sei vorweggenommen, dass sowohl objektorientierte Programmiersprachen als auch Prolog hierarchische Modularisierungskonzepte anbieten. Solche Konzepte bieten gewisse Basismodule, welche in immer größeren Moduleinheiten zusammengefasst werden können. Die dabei entstehende Hierarchie formt die Struktur des Systems. So lassen sich beispielsweise in objektorientierten Prgrammiersprachen Daten und auf ihnen auszuführende Operationen zu Objekten zusammenfassen. Objekte wiederum können zu Klassen von Objekten mit ähnlichem Verhalten gruppiert werden. Durch die 5

12 2 Grundlagen der Aspektorientierung 1 class Account{ 2 private int balance = 0; 3 private TransactionLog log = new TransactionLog(); 4 5 public void deposit(int amount) { 6 if!(balance >= -amount) 7 throw new BalanceException(balance, amount); 8 balance += amount; 9 log.addentry(balance); 10 } } Abbildung 2.1: Implementation zweier Crosscutting Concerns. Nutzung von Vererbung entsteht eine Klassenhierarchie. Weitere übergeordnete Modularisierungskonzepte wie Pakete führen diese Hierarchisierung fort Crosscutting Concerns Bei der Implementation eines Software-Systems kann es vorkommen, dass ein Concern nicht modularisiert wird. Die Implementation dieses Concerns verteilt sich dann auf die Implementation anderer Concerns. Eine Ursache hierfür kann darin liegen, dass das Concern während der Implementation nicht als eigenständig berücksichtigt wurde. In diesem Fall kann eine nachträgliche Modularisierung Abhilfe schaffen. Im Gegensatz dazu gibt es Concerns, welche sich mit Hilfe hierarchischer Konzepte nicht modularisieren lassen. Die Implementation dieser Crosscutting Concerns ist mit den Implementationen anderer Concerns vermischt, ohne dass eine Trennung möglich ist [43]. Definition 2 (Crosscutting Concern) Ein Crosscutting Concern ist ein Concern, welches sich unter Verwendung hierarchischer Modularisierungskonzepte nicht modularisieren lässt und daher die Modularisierung anderer Concerns beeinflusst. Crosscutting Concerns führen zu einer engen Kopplung des Systems. Somit werden Verständlichkeit, Wartbarkeit, Erweiterbarkeit und Wiederverwendbarkeit der Implementation erschwert. Oftmals ist das Crosscutting dabei im Wesen des Concerns verankert. Die Abschnitte 3.2 und 4.2 identifizieren typische Crosscutting Concerns für objektorientierte Programmiersprachen respektive Prolog. Abbildung 2.1 zeigt die Implementation einer Klasse Account zur Verwaltung eines Bankkontos in der objektorientierten Programmiersprache Java. Die gezeigte Klasse modularisiert die Daten des Kontos und die auf dem Konto auszuführenden Operationen. Neben dieser Implementation der Kernfunktionalität weist die Klasse die Implementation zweier weiterer Concerns auf, welche in unterschiedlichen Grautönen unterlegt sind. 6

13 2.2 Aspektorientierte Programmierung 1 class Account{ 2 private int balance = 0; 3 public void deposit(int amount) { 4 balance += amount; 5 } } Abbildung 2.2: Komponente ohne Implementationen von Crosscutting Concerns. Das erste Concern adressiert das Logging von Transaktionen. Jedes Konto erhält ein eigenes Logging-Objekt. Nach erfolgreicher Abarbeitung der Methode deposit(int) wird der neue Kontostand aufgezeichnet. Dieses Concern ist ein typisches Crosscutting Concern. Die Implementation verteilt sich auf verschiedene Kontoklassen und -methoden. Dies hat schwerwiegende Auswirkungen auf die Wartbarkeit und Erweiterbarkeit der Implementation. Ändert sich beispielsweise die Signatur des Logging-Objekts, ergeben sich Änderungen an allen Klassen, welche Methoden enthalten, die den Kontostand beeinflussen. Das zweite Concern beinhaltet die Prüfung einer Vorbedingung. Wie das Logging bildet auch dieses ein typisches Crosscutting Concern. 2.2 Aspektorientierte Programmierung Komponenten und Aspekte Aspektorientierte Programmiersprachen bieten neben herkömmlichen hierarchischen Konzepten ein zusätzliches Modularisierungskonzept für Crosscutting Concerns. Concerns, welche von Crosscutting Concerns beeinflusst werden, können so ohne deren Einflüsse separat als Komponenten durch Nutzung hierarchischer Konzepte modularisiert werden. Definition 3 (Komponente) Eine Komponente modularisiert ein Concern mit Hilfe hierarchischer Modularisierungskonzepte. Abbildung 2.2 zeigt die auf diese Art um die Implementation von Crosscutting Concerns bereinigte Klasse Account. Die Crosscutting Concerns können dann als Aspekte modularisiert werden. Definition 4 (Aspekt) Ein Aspekt modularisiert ein Crosscutting Concern eines Programms. Ein Aspekt beschreibt dabei den Einfluss eines Crosscutting Concerns auf die Implementation von Komponenten und anderen Aspekten. Als Modularisierungskonzept bieten Aspekte eine zu hierarchischen Konzepten orthogonale Möglichkeit der Modularisierung [88]. Dabei weisen Aspekte neue, von hierarchischen Konzepten unbekannte Eigenschaften auf. So überlappen Aspekte andere Module, sowohl Komponenten als auch andere Aspekte. Dies ermöglicht erst die Implementation von Crosscutting Concerns. 7

14 2 Grundlagen der Aspektorientierung 1 aspect Logging{ 2 private TransactionLog Account.log = new TransactionLog(); 3 after(account ac, int nb): set(int Account.balance) && target(ac) && args(nb) { 4 ac.log.addentry(nb); 5 } 6 } 1 aspect DesignByContract{ 2 before(account ac, int amount): execution(account.deposit(int)) && 3 target(ac) && args(amount) { 4 if!(ac.balance >= -amount) 5 throw new BalanceException(ac.balance, amount); 6 } 7 } Abbildung 2.3: Implementation von Crosscutting Concerns als Aspekte. Abbildung 2.3 zeigt die Implementation der beiden Crosscutting Concerns aus dem Kontobeispiel als Aspekte. Als Beschreibungssprache dient dabei AspectJ, eine aspektorientierte Erweiterung von Java, welche in Abschnitt 3.3 vorgestellt wird. Der Logging- Aspekt erweitert die Klasse Account um eine zusätzliche Membervariable, welche das Logging-Objekt aufnimmt. Des Weiteren spezifiziert der Aspekt, dass nach jeder Veränderung des Kontostandes der neue Wert dort vermerkt wird. Der zweite Aspekt implementiert die Prüfung einer Vorbedingung, welche sicherstellt, dass Abbuchungen den aktuellen Kontostand nicht übersteigen Webevorgang Eine wesentliche Fragestellung beim Entwurf einer aspektorientierten Programmiersprache ist die der Komposition von Modulen zu einem Gesamtprogramm. Diese Komposition erfolgt durch einen sogenannten Weber. Der Weber berücksichtigt dabei die als Aspekte implementierten Crosscutting Concerns und webt diese in die Komponenten ein. Der Vorgang kann zu unterschiedlichen Zeitpunkten geschehen. Danach lassen sich statische (Komposition zur Übersetzungszeit) und dynamische Weber (Komposition zur Laufzeit) unterscheiden. Eine weitere Möglichkeit besteht in der Komposition zur Ladezeit eines Programms. Eine aspektorientierte Programmiersprache kann sich aus mehreren Teilsprachen zusammensetzen. So kann es verschiedene Beschreibungssprachen für Komponenten, Aspekte und das durch den Weber erzeugte Programm geben. Vor allem die Beschreibungssprache für die Aspekte orientiert sich dabei zumeist an einer bestimmten Art von Crosscutting Concerns, welche modularisiert werden sollen. Spezielle Komponentensprachen bieten sich an, wenn für eine Steuerung des Webevorgangs eine höhere Stufe der Abstraktion als in der Ausgabesprache von Nöten ist. Beispielsweise enthält die Kom- 8

15 2.2 Aspektorientierte Programmierung ponentensprache in [45] Abstraktionen für Schleifen, welche bei der Optimierung des Gesamtprogramms durch den Weber genutzt werden. Oft wird jedoch ein allgemeinerer Ansatz gewählt und eine bestehende Programmiersprache um ein zusätzliches Modularisierungskonzept für Crosscutting Concerns erweitert. Komponenten können dann in der ursprünglichen Sprache implementiert werden, während Aspekte mittels der neuen Sprachkonstrukte beschreibbar sind. Oftmals erzeugt ein statischer Weber dann Programme in der Ausgangssprache, womit deren Übersetzer, Laufzeitumgebungen, Bibliotheken und weitere Tools weiter nutzbar sind Joinpoint-Modelle Für den Entwurf einer Beschreibungssprache für Aspekte ist es eine naheliegende Idee, Beschreibungsmittel für das Crosscutting eines Aspekts zur Verfügung zu stellen und diese Beschreibungen dann beim Webevorgang zu nutzen. Vor allem durch den Einfluss von AspectJ [44, 6] haben sich Joinpoint-Modelle als Grundlage für dieses Vorgehen etabliert. Ein Joinpoint-Modell legt zunächst Punkte fest, an denen ein Aspekt eine Komponente oder einen anderen Aspekt generell beeinflussen kann. Lediglich an solchen Joinpoints können Aspekte eingewoben werden. Definition 5 (Joinpoint) Ein Joinpoint ist ein wohldefinierter Punkt eines Programms, an dem ein Aspekt das Verhalten des Programms beeinflussen kann. Dabei kann sich ein Joinpoint-Modell auf die statische Struktur, d.h. auf Punkte im Quelltext als Joinpoints, oder auf die dynamische Struktur, d.h. auf Punkte in der Ausführung des Programms, beziehen. Hiernach lassen sich statische und dynamische Joinpoint-Modelle unterscheiden. Ein statisches Joinpoint-Modell legt einen Webevorgang zur Übersetzungs- oder Ladezeit eines Programms nahe, kann unter Umständen aber auch durch einen dynamischen Weber umgesetzt werden. Umgekehrt lässt sich ein dynamisches Joinpoint-Modell durch das Einweben dynamischer Tests in den Quellcode eines Programms statisch umsetzen. Des Weiteren definiert ein Joinpoint-Modell, wie Teilmengen von Joinpoints beschrieben werden können. Die Beschreibung solcher Pointcuts spezifiziert dann Orte des Crosscuttings eines Aspekts. Definition 6 (Pointcut) Ein Pointcut ist eine Teilmenge aus der Menge aller Joinpoints eines Programms. Ein Pointcut kann Werte aus dem Ausführungskontext dieser Joinpoints referenzieren. Abschließend legt das Joinpoint-Modell fest, wie ein Aspekt das Verhalten an Joinpoints eines Pointcuts beeinflussen kann. Dieser Einfluss wird mit Hilfe von Advices formuliert. Definition 7 (Advice) Ein Advice beschreibt den Einfluss eines Aspekts auf das Verhalten an allen in einem Pointcut enthaltenen Joinpoints. 9

16 2 Grundlagen der Aspektorientierung Damit ermöglicht ein Joinpoint-Modell die Beschreibung von Aspekten folgenderweise: Zunächst werden mittels Pointcut-Beschreibungen die Stellen im Programm deklariert, welche durch den Aspekt beeinflusst werden. Dann wird durch die Zuordnung von Advices zu Pointcuts bestimmt, wie das Verhalten an diesen Stellen verändert wird. Für gewöhnlich enthalten Advices dabei zusätzliche oder alternative Implementationen, welche am Joinpoint zur Ausführung kommen. 10

17 3 Aspektorientierung aus objektorientierter Sicht Die Ideen der aspektorientierten Programmierung sind maßgeblich durch Erweiterungen des objektorientierten Paradigmas geprägt. Daher werden in diesem Kapitel zunächst die Modularisierungskonzepte objektorientierter Programmiersprachen betrachtet. Darauf basierend werden typische Anwendungsfälle für Crosscutting Concerns identifiziert. Im folgenden Kapitel werden diese Darstellungen aufgegriffen und zum Vergleich mit der Situation in Prolog genutzt. Im zweiten Teil dieses Kapitels werden mit AspectJ und der Method-Call Interception zwei Ansätze zur Integration aspektorientierter Programmierung in objektorientierte Sprachen vorgestellt. AspectJ erweitert die Programmiersprache Java und hat das aspektorientierte Paradigma entscheidend geprägt. Die Method-Call Interception verfolgt einen allgemeineren Ansatz und zeigt, dass sich durch ein zusätzliches Sprachkonstrukt Aspektorientierung in beliebige objektorientierte Sprachen integrieren lässt. 3.1 Modularisierungskonzepte Objektorientierte Programmiersprachen bieten verschiedene hierarchische Konzepte zur Modularisierung einer Implementation. Analog zum Prozedurkonzept imperativer Programmiersprachen lassen sich Algorithmen in Methoden modularisieren. Dabei hängen Methoden von anderen Methoden, welche sie aufrufen, ab. Hieraus ergibt sich oftmals eine hierarchische Organisation der Methoden. Objekte fassen Datenstrukturen und Methoden, welche Operationen auf diesen ausführen, zur Laufzeit zusammen. Klassen bieten ein korrespondierendes Modularisierungskonzept zur Übersetzungszeit. Durch die Nutzung von Vererbung ergibt sich eine Klassenhierarchie. Übergeordnete Konzepte wie Pakete fassen Klassen und andere Pakete zusammen, was erneut zu einer hierarchischen Organisation führt. Crosscutting Concerns können sich auf allen Modularisierungsebenen auswirken. So ist es möglich, dass die Implementation eines Crosscutting Concerns die Modularisierung eines Algorithmus als Methode durchzieht. Unter Umständen sind davon mehrere Methoden in unterschiedlichen Klassen betroffen. Darüber hinaus ist es möglich, dass ein Crosscutting Concern nur ausgewählte Objekte einer Klasse, nicht aber die gesamte Klasse, betrifft. Dies ist beispielsweise der Fall, wenn die Ausführung des Concerns vom Zustand der betroffenen Objekte abhängt. 11

18 3 Aspektorientierung aus objektorientierter Sicht 3.2 Typische Anwendungen Optimierungen Eines der ersten identifizierten Crosscutting Concerns adressiert die Effizienz eines Systems [45]. Um ein System effizienter zu gestalten, wird die Implementation der Systemfunktionalität optimiert. Dabei kann es von Vorteil sein, getrennte Implementationen zu koppeln, etwa bei der Optimierung von Schleifen. Diese Kopplung führt somit zu Crosscutting, obwohl die Implementationen ohne Berücksichtigung der Effizienz modularisierbar sind. Tracing und Logging Die Ausgabe von Informationen an bestimmten Punkten eines Programmes ist eines der Standardbeispiele für Crosscutting Concerns, da die Anweisungen zur Ausgabe die Implementation der eigentlichen Funktionalität des Programms durchziehen. Solche Ausgaben können während des Debuggings nützlich sein, um die Abarbeitungsreihenfolge des Programms nachvollziehen und eventuelle Fehler finden zu können (Tracing). Ferner können individuelle Ausgaben über ausgeführte Systemaktionen zu Zwecken der Wartung oder zur Rückverfolgung eines Systemzustands genutzt werden (Logging). Fehlerbehandlung Eine einheitliche Strategie zur Behandlung von Fehlern ist ebenfalls ein typisches Crosscutting Concern. Die entsprechende Umsetzung der Fehlerbehandlung ist über Module, in denen die Fehler auftreten können, verteilt. Persistenz Sollen die Daten eines Systems persistent gehalten werden, muss die Datenhaltung an zahlreichen Stellen im Programm entsprechend angepasst werden. Somit handelt es sich auch hier um ein Crosscutting Concern. Synchronisation Die Synchronisation von Systemoperationen stellt ein weiteres Crosscutting Concern dar, da zusätzliche Anweisungen in der Implementation dieser Operationen die Synchronität gewährleisten. Design by Contract Die objektorientierte Programmiersprache Eiffel [62] stellt mit dem Konzept des Design by Contract einen nahtlosen Ansatz zur Integration von Spezifikation, Entwurf und Implementation einer Software zur Verfügung. Dabei werden Spezifikationen sowohl in den Entwurf als auch in die Implementation integriert. Dies ist formal durch Zusicherungen in Form von Vor- und Nachbedingungen möglich. Durch eine spezielle Compiler-Option ist es möglich, diese Bedingungen zur Laufzeit prüfen zu lassen. Das Konzept lässt sich auf andere objektorientierte Programmiersprachen übertragen [40]. Durch die fehlende Integration in die Syntax dieser Sprachen müssen die Prüfungen allerdings von Hand implementiert werden. Die Vor- und Nachbedingungen stellen hierbei Crosscutting Concerns dar [82]. Ihre Implementation durchsetzt die eigentliche Implementation des Entwurfs. Durch eine Modularisierung der Spezifikationsfragmente 12

19 3.3 AspectJ als Aspekt ist es möglich, die Implementation von der Prüfung der Vor- und Nachbedingungen zu trennen. Darüber hinaus ist es so möglich, die reine Implementation als effiziente Version ohne Prüfung der verschiedenen Bedingungen zu nutzen. 3.3 AspectJ Eine der meistbeachteten Umsetzungen aspektorientierter Programmierung für objektorientierte Programmiersprachen ist AspectJ [44, 6]. Daher werden im folgenden Abschnitt die grundlegenden Ideen, welche sich im Umfeld von AspectJ gebildet haben, vorgestellt. Dabei werden auch bereits eingeführte Begriffe, welche AspectJ entscheidend geprägt hat, nochmals erläutert. Im weiteren Verlauf der Arbeit werden dann aspektorientierte Ansätze mit AspectJ in Verbindung gesetzt Anliegen Mit AspectJ verbindet sich der Versuch, die Diskussion um aspektorientierte Programmierung durch empirische Untersuchungen voranzutreiben. Hauptziel ist es dabei, eine Benutzergemeinschaft aufzubauen, welche aspektorientierte Programmierung betreibt. Diese Gemeinschaft soll dann Informationen liefern, welche Eigenschaften aspektorientierte Programmierung in der reellen Verwendung aufweist. Dabei ist es auch beachtenswert, ob die erhofften Vorteile, wie sie in [45] beschrieben sind, tatsächlich zum Tragen kommen. AspectJ bildet in diesen Bemühungen lediglich die Grundlage, indem es eine aspektorientierte Programmiersprache bereitstellt. Hierbei wird der Ansatz verfolgt, keine eigene Sprache zur Beschreibung der Aspekte zu verwenden, sondern stattdessen eine existierende Sprache um Beschreibungsmöglichkeiten für Aspekte zu erweitern. Dadurch werden sowohl Komponenten als auch Aspekte in einer Sprache beschrieben. Da die Komponenten mit Sprachanteilen einer bereits existenten Programmiersprache beschrieben werden, ist der Einstieg in die neue Programmiersprache dementsprechend leicht. Im Falle von AspectJ bildet Java die Grundlage der Erweiterung. Alle Java-Programme formen so auch AspectJ-Programme, welche lediglich aus Komponenten bestehen. Neben dieser Aufwärtskompatibilität wurde bei der Erweiterung auf weitere Kompatibilität geachtet, so dass der Umstieg von Java auf AspectJ möglichst einfach zu vollziehen ist. Dies betrifft einerseits die Plattformkompatibilität, welche es ermöglicht, alle AspectJ- Programme auf Java Virtual Machines auszuführen. Weitere wichtige Punkte im Aufbau einer Benutzergemeinschaft bilden die Toolkompatibilität und die Benutzerkompatibilität. Erstere ermöglicht die sukzessive Erweiterung von Java-Entwicklungstools zur Verwendung mit AspectJ. Letztere versucht dem AspectJ-Programmierer das Gefühl zu geben, wie in Java zu programmieren. 13

20 3 Aspektorientierung aus objektorientierter Sicht Dynamisches Joinpoint-Modell Die Idee, zur Beschreibung von Aspekten Joinpoint-Modelle zu verwenden, wurde durch AspectJ entscheidend geprägt. Dabei wurden zunächst verschiedene Modelle untersucht. Letztlich ergab sich ein dynamisches Joinpoint-Modell, welches im Folgenden erläutert wird. Joinpoints Das Joinpoint-Modell von AspectJ orientiert sich an der Ausführung des Programms. Es beschreibt verschiedene Arten dynamischer Joinpoints als Punkte in der Programmausführung. Diese sind der Aufruf einer Methode oder eines Konstruktors, der Empfang eines Methoden- oder Konstruktoraufrufs, die Ausführung einer Methode oder eines Konstruktors, das Lesen oder Schreiben eines Feldes, die Ausführung einer Ausnahmebehandlung und die Initialisierung von Klassen oder Objekten. Jeder Joinpoint wird dabei zweimal passiert. Zunächst geschieht dies vor der Ausführung der mit dem Joinpoint verknüpften Aktion. Anschließend wird der Joinpoint nach Ausführung der Aktion erneut passiert. Pointcuts Pointcuts umfassen Joinpoints, an denen ein Aspekt durch Advices das Verhalten des Programms beeinflusst. Sie lassen sich in AspectJ auf verschiedene Art und Weise beschreiben. Den Ausgangspunkt bilden dabei primitive Pointcut-Beschreibungen. Für jede Art von Joinpoints ist eine solche Beschreibung vorgesehen. So beschreibt zum Beispiel calls(signature ) die Menge aller Joinpoints, an denen eine Methode der Signatur Signature aufgerufen wird. In der Signatur werden dabei Ergebnistyp und Parametertypen berücksichtigt, wobei die üblichen Untertyp-Relationen zur Anwendung kommen. Zusätzlich können sowohl bei den Typen als auch beim Methodennamen Wildcards benutzt werden. Des Weiteren bietet AspectJ auch primitive Pointcut-Beschreibungen, welche Joinpoints unterschiedlicher Arten adressieren. So ist es möglich, mittels within(classname ) die Menge aller Joinpoints in Objekten der Klasse ClassName zu beschreiben. Der Programmierer kann unter Verwendung primitiver Beschreibungen und logischer Kombinatoren benutzerdefinierte Pointcut-Beschreibungen erstellen. Diese können entweder unbenannt sein oder zur weiteren Verwendung mit einem Namen versehen werden. Darüber hinaus ist es möglich, Werte aus dem Ausführungskontext durch den Pointcut zu referenzieren. Typische solcher Werte sind beispielsweise aktuelle Parameter eines Methodenaufrufs oder das Empfängerobjekt eines solchen Aufrufs. Advice Ein Aspekt kann das Verhalten an den Joinpoints eines Pointcuts beeinflussen. Dieser Einfluss wird durch die Zuordnung von Advices zu Pointcuts beschrieben. Das Joinpoint- Modell von AspectJ ermöglicht als Advices zusätzlichen oder alternativen Programm- 14

21 3.3 AspectJ code. Dabei sind drei Arten von Advices vorgesehen. Before-Advices beschreiben Programmcode, der beim Eintritt in einen durch den Pointcut adressierten Joinpoint, also vor der Ausführung der mit dem Joinpoint verknüpften Aktion, ausgeführt werden soll. After-Advices ermöglichen hingegen die Beschreibung von Programmcode, der bei Verlassen des Joinpoints, also nach der Ausführung der verknüpften Aktion, auszuführen ist. Around-Advices bieten die Möglichkeit, Programmcode an Stelle der mit dem Joinpoint verknüpften Aktion zur Ausführung kommen zu lassen. Dabei kann in einem solchen Advice mittels einer Proceed-Anweisung die ursprüngliche Aktion des Joinpoints mit eventuell veränderten Parametern zur Ausführung gebracht werden. Aspekte Mit Hilfe von Pointcut- und Advice-Deklarationen lassen sich in AspectJ Aspekte separat beschreiben. Aspekte bilden damit ein neues Modularisierungskonzept zur Implementation von Crosscutting Concerns. Die Modularisierung der Crosscutting Concerns durch Aspekte befindet sich dabei auf einer Ebene mit der Modularisierung durch Klassen. Daher werden in AspectJ Aspekte auch ähnlich wie Klassen deklariert. Neben Pointcutund Advice-Deklarationen können diese weitere Deklarationen enthalten, wie sie auch in Klassendeklarationen vorkommen. Zur Laufzeit gibt es gewöhnlich zu jedem Aspekt genau eine Instanz, in deren Kontext die verschiedenen Advices ausgeführt werden Übersetzung Damit AspectJ-Programme gemäß der geforderten Plattform-Kompatibilität auf Java Virtual Machines ausgeführt werden können, müssen diese in Java Bytecode übersetzt werden. AspectJ selbst schreibt dabei nicht vor, wann Aspekte und Komponenten, d.h. Klassen, miteinander verwoben werden. Die Entwickler der Sprache bieten jedoch eine Implementation an, welche den Webevorgang soweit wie möglich zur Übersetzungszeit vollzieht. Zur Umsetzung wird der Quellcode des Programms schrittweise transformiert. Programmteile, in denen keine Advices zur Anwendung kommen, bleiben dabei unverändert. In allen anderen Programmteilen werden Stellen im Programmcode untersucht, welche mit dynamischen Joinpoints korrespondieren. Besteht die Möglichkeit, dass eine Pointcut-Beschreibung einen Joinpoint adressiert, werden statische Veränderungen an der entsprechenden Programmstelle vorgenommen. Hierzu wird der zu einem dynamischen Joinpoint gehörige Code durch eine korrespondierende Methode umhüllt. Eventuell kann für einen Joinpoint erst zur Laufzeit entschieden werden, ob dieser durch einen Pointcut adressiert wird, und somit bestimmte Advices zur Ausführung gelangen. In diesem Fall werden innerhalb der Methode entsprechende dynamische Tests generiert. Ein Advice, das an einem durch einen Pointcut adressierten Joinpoint zur Ausführung kommen soll, wird dann aus der korrespondierenden Methode heraus zur Ausführung gebracht. Um dies zu ermöglichen, werden die Körper von Advice-Deklarationen in Java- Methoden transformiert. 15

22 3 Aspektorientierung aus objektorientierter Sicht 3.4 Method-Call Interception Die Method-Call Interception [55] bietet eine weitere Möglichkeit, objektorientierte Programmiersprachen um ein Konzept zur Beschreibung von Crosscutting Concerns zu erweitern. Im Ansatz ähnelt die Beschreibung zwar AspectJ, jedoch erfolgt die Integration in die existierende Sprache auf völlig anderem Wege, weshalb diese Idee hier kurz Beachtung finden soll Anliegen Die Idee der Method-Call Interception ist es, an bestimmten Punkten um die Ausführung von Methoden zusätzliche Funktionalität zur Ausführung kommen zu lassen. Dieses Konzept kann durch ein zusätzliches Sprachkonstrukt in eine existente objektorientierte Programmiersprache eingeführt werden. Damit unterscheidet sich die Method-Call Interception im Ansatz nicht von anderen Ansätzen, wie z.b. AspectJ, welche ähnliche Ausdrucksmöglichkeiten bieten. Während in AspectJ und anderen Implementationen jedoch Programmtransformationen und Reflection zur Umsetzung des Webevorgangs zur Anwendung kommen, zeigt die Method-Call Interception, dass es auf einfache Art und Weise möglich ist, aspektorientierte Sprachkonzepte in die Semantikdefinition einer Sprache einzubinden. Damit haben solche Konstrukte keinen Sonderstatus mehr innerhalb der Sprache Dynamisches Joinpoint-Modell Dem Ansatz der Method-Call Interception liegt ein Modell zugrunde, welches beschreibt, an welchen Punkten zusätzliche Funktionalität zur Ausführung kommen kann. Darüber hinaus bildet dieses Modell die Grundlage zur Koordination von Basis- und zusätzlicher Funktionalität. Im Folgenden wird dieses als dynamisches Joinpoint-Modell betrachtet und unter der Verwendung der durch AspectJ geprägten Begriffe beschrieben. Joinpoints In AspectJ gibt es drei Arten von dynamischen Joinpoints, welche bei der Ausführung von Methoden passiert werden. Dies sind der Aufruf einer Methode, der Empfang eines Methodenaufrufs und die Ausführung der Methode. Jeder dieser Joinpoints wird dabei zweimal durchschritten, jeweils vor und nach der Ausführung der mit ihm verbundenen Aktion. Im Joinpoint-Modell der Method-Call Interception wird jede dieser beiden Möglichkeiten separat betrachtet. Von den somit sechs Möglichkeiten werden lediglich drei als Joinpoints aufgefasst, da sowohl auf Joinpoints vor und nach dem Empfang eines Methodenaufrufs, als auch auf Joinpoints nach dem Aufruf einer Methode verzichtet wird. Die verbleibenden drei Arten von Joinpoints veranschaulicht Abbildung 3.1. Den Zusammenhang zu Joinpoint- und Advice-Arten in AspectJ zeigt Tabelle 3.1 auf. 16

23 3.4 Method-Call Interception enter <o, mn> <o, mn > exp.mn (...) dispatch Abbildung 3.1: Joinpoints bei der Abarbeitung von Methodenaufrufen in objektorientierten Programmiersprachen. exit Die erste Art bilden Dispatch-Punkte. Diese werden nach der Berechnung des Empfängerobjekts für einen Methodenaufruf (Dispatch), aber vor der Berechnung der Argumente der Methode, passiert. Zusätzliche Funktionalität, welche an einem solchen Punkt zur Ausführung gelangt, entspricht einem Before-Advice für einen Methodenaufruf in AspectJ. Nach der Berechnung der zusätzlichen Argumente wird der Methodenkörper einer aufgerufenen Methode betreten. Dabei durchschrittene Enter-Punkte bilden die zweite Art von Joinpoints. In AspectJ kann an diesen Punkten mittels Before- Advice für Methodenausführungen zusätzliche Funktionalität zur Ausführung gelangen. Die dritte Art von Joinpoints bilden die Exit-Punkte, welche beim Austritt aus einem Methodenkörper erreicht werden. AspectJ bietet die Möglichkeit, über After-Advice für Methodenausführungen an diesen Punkten zusätzliche Funktionalität anzubringen. Pointcuts Zur Platzierung von Advice wird auch bei der Method-Call Interception eine Pointcut- Beschreibung für Mengen von Joinpoints verwendet. Dabei werden grundsätzlich nur Joinpoints einer Art beschrieben, d.h. entweder Dispatch- oder Enter- oder Exit-Punkte. Diese Beschränkung ist jedoch willkürlich. Unter Verwendung einer anderen Syntax ist eine Pointcut-Beschreibung, welche Joinpoints unterschiedlicher Art umfasst, möglich. Neben der Art der Joinpoints qualifiziert eine Pointcut-Beschreibung über Eigenschaften von Methodenaufrufen. Hierzu gehören das Empfängerobjekt des Methodenauf- AspectJ-Joinpoint Advice MCI-Joinpoint Methodenaufruf before dispatch after Methodenempfang before after Methodenausführung before enter after exit Tabelle 3.1: Zusammenhang zwischen den Joinpoint-Modellen von AspectJ und Method- Call Interception. 17

24 3 Aspektorientierung aus objektorientierter Sicht rufs, die Klasse dieses Objektes, der Methodenname, der Ergebnistyp und die Argumente der Methode. Für jede dieser Eigenschaften existieren primitive Pointcut-Beschreibungen, welche wie in AspectJ mittels logischer Operatoren kombiniert werden können. Eine Parametrisierung mit Daten aus dem Kontext des Methodenaufrufs ist im Gegensatz zu AspectJ nicht nötig, da die Interaktion mit dem Kontext auf anderem Wege realisiert wurde. Darüber hinaus kann eine Pointcut-Beschreibung durch eine weitere Pointcut-Beschreibung qualifiziert werden, welche angibt, innerhalb welches Kontextes eine Methode aufgerufen wird. So umfasst der Pointcut enter method a within method b alle Enter-Punkte der Methode a, welche während der Abarbeitung der Methode b durchschritten werden. Pointcut-Beschreibungen der Method-Call Interception sind grundsätzlich anonym, da sie nur in Kombination mit Advice, welches an den enthaltenen Joinpoints zur Ausführung gelangen soll, verwendet werden. Auch dies ist zunächst nur der Syntax der Beispielsprache zur Method-Call Interception geschuldet. Eine entsprechende Erweiterung der Syntax und Semantik um Pointcut-Variablen ist theoretisch möglich. Advices Advices folgen einer anonymen Pointcut-Beschreibung und enthalten einen Ausdruck, welcher an Joinpoints, welche durch diese Beschreibung erfasst werden, evaluiert werden soll. Innerhalb dieses Ausdrucks ist es dabei möglich, mit dem Kontext eines Methodenaufrufs zu interagieren. Hierzu werden in die Ausgangssprache zusätzliche Ausdrücke zum Zugriff auf den Sender und den Empfänger eines Methodenaufrufs sowie für den Zugriff auf die Argumente und das Ergebnis des Aufrufs eingeführt. Aspekte Die Method-Call Interception verzichtet auf ein gesondertes Sprachkonstrukt für Aspekte. Stattdessen wird in die Ausgangssprache ein zusätzlicher Ausdruck eingeführt, welcher die Platzierung von Advices ermöglicht. Solche Platzierungsausdrücke können also an allen Stellen eines Programms auftreten, an denen auch andere Ausdrücke erlaubt sind. Um einen Aspekt zu modularisieren, kann man jedoch auf die Modularisierung durch eine Klasse zurückgreifen. In der Initialisierungsmethode können dann sämtliche Platzierungsausdrücke des Aspektes zusammengefasst werden. Zusätzlich bietet eine solche Modularisierung die Möglichkeit, aus den Advice heraus auf Methoden und Felder der Aspekt-Klasse zurückzugreifen. Auf diese Art lassen sich Informationen eines Crosscutting Concerns zentral verwalten. 18