universität bonn, seminar component and aspect engineering ws 2003/2004, dirk schiele 1...

Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 1

Aspekt-Interferenzen

Seminar Component and Aspect Engineering

Uni Bonn, WS 2003/2004

Dirk Schiele


Inhaltsübersicht

Motivation Wiederholung AOP Was sind Interferenzen? Wodurch entstehen sie?

Analyse an Hand zentraler Features von AspectJ Interface Introduction Class Introduction Änderung der Klassenhierarchie Auswirkungsanalyse Beispiel

Zusammenfassung / Ausblick


Motivation - Wozu AOP?

AOP (Aspect Oriented Programming) Ziel:

Kapselung von modulübergreifenden Implementierungsinteressen (Aspekten) wie z.B.: Sicherheit effiziente Speicherverwaltung Echtzeitverhalten etc.

um folgendes zu erreichen: Vermeidung von verteiltem und verwirrendem Sourcecode bessere Strukturierung (Trennung von funktionaler Implementierung) einfachere Entwicklung und Wartbarkeit


Motivation - Wie macht's AspectJ?

AspectJ Java-Erweiterung Aspekte und Funktionen werden getrennt implementiert Verbindung

Join Points (Methodennamen, Ausführungszeitpunkt) Klassennamen

Aspect-Weaver „webt“ die Aspekte zur Compilezeit (oder auch Lade- oder Laufzeit) in das Basissystem ein


Motivation - Interferenzen Was sind Interferenzen?

gewollte oder ungewollte Einflüsse von Aspekten(z.B. falsche Methodenaufrufe)

Änderung des Verhaltens des gesamten Systems Wodurch entstehen sie?

Interface Introduction Einfügung von zusätzlichen Interface-Implementierungen

Class Introduction Einfügung von zusätzlichen Feldern/Methoden in Klassen

"Declare-Parents" Änderungen an der Vererbungshierarchie

Advice Ausführung zusätzlicher Funktionen

Problem: geteilte Implementierung von Aspekten und Funktionen Änderungen sind nicht direkt im Sourcecode sichtbar


Motivation - Beispiel

Vererbungshierarchie

class A { void n(); }

class B extends A{ void n(); }

class C extends A {}

aspect L { declare parents: C extends B; }

A

CB

A.n

A.nB.n

A

C

B

A.n

B.n

B.n


Analyse an Hand von AspectJ-Features

Interface Introduction Beschreibung mögliche Interferenzen Analysevorgehen

Class Introduction Beschreibung mögliche Interferenzen Analysevorgehen

Änderung der (Vererbungs-) Klassenhierarchie Beschreibung mögliche Interferenzen Analysevorgehen

Output: Warnungen, Menge von unbedenklichen Aspekt-Operationen, Menge von zu wiederholendenTest-Treibern

Input: Basissystem, Aspekt-Code,Menge von Test-Treibern

Interface Introd.

Auswirkungsanalyse

Declare-Parents

Class Introduction


Interface Introduction

Beschreibung nachträgliche / zusätzliche Implementierungen von Schnittstellen Ziel: Default-Methoden

zur Arbeitserleichterung bei der Programmierung um ggf. Mehrfachvererbung abbilden zu können

mögliche Interferenz: vergessene (Re-)Definitionen in implementierenden Klassen

Compilerwarnung wäre sinnvoll


A

B

CC.x D.xD.y

C.x

G D

FE D.xD.y


Beispiel:

class A { void n() { print("A.n()"); }} class B extends A { void m() { print("B.m()"); }}class C extends B { public void x() { print("C.x()"); }} class D extends B { public void y() { print("D.y()"); } public void x() { print("D.x()"); }}class E extends C {} class F extends D { void n() { print("F.n()"); }}class G extends B { void n() { print("G.n()"); }}interface I { void x(); void y();}

I.y

I.y

I.yaspect M { declare parents: C implements I;declare parents: D implements I;public void I.y() { print("I.y()"); }}

IA

B

CC.x D.xD.y

C.x

G D

FE D.xD.y


Analyse bestimme Menge der Interfaces

aus Aspekt A: Idef

bestimme Menge der Klassen, die ein Interface aus Idef implementieren: Cldef

bestimme die Klassen aus Cldef, die

nicht alle Methoden des entsprechenden Interfaces erneut definieren

Programmierer muß jeweils prüfen, ob die Methoden verwendet werden sollen


C C.x D.xD.y

C.x

G D

A

B

FE D.xD.y

I I.y

I.y

I.y


Class Introduction

Beschreibung zusätzliche Felder / Methoden zu Klassen hinzuzufügen Ziel: Erweiterung der Funktionalität (z.B. Persistenz)

mögliche Interferenz: "Binding Interference" OOP -> "Dynamic Binding"

es wird erst zur Laufzeit entschieden, welche Methode ausgeführt werden soll (Polymorphismus)

Änderungen in Klassen kann Auswirkungen auf die Vererbung von Methoden und damit auf die Ausführung geerbter Methoden haben

ggf. über mehrere Ebenen hinweg


Class Introduction

Beispiel:

aspect N { void B.n() { print("B.n()"); }}

A

B

A.nB.m

A.nB.m

A.nB.m

G D

F F.nB.m

G.nB.m

A.nB.m

A.n

B.nB.m

B.nB.m

B.nB.m

B.nB.m

C

E


Class Introduction

Bemerkungen durch die getrennte Implementierung sind die Interferenzen im

Basiscode nicht zu erkennen beide Teile, Basiscode und Aspektcode, müssen parallel betrachtet

werden Semantik des Systems ändert sich ggf. extrem Java-Zugriffsbeschränkungen schränken die mögliche

Interferenzmenge ggf. ein (z.B. falls Methoden in Subklassen nicht sichtbar sind - "private") hier wird zur Vereinfachung nur von public-Definitionen ausgegangen


Class Introduction

Analyse nach Anwendung des Aspekts muß das "No-Interference"-Kriterium

gelten:

um mögliche semantische Änderungen aufzudecken dazu Prüfung, ob sich Quellen geerbter Methoden geändert haben

(Betrachtung der Methodenrümpfe nicht notwendig)

alle möglichen Aufrufe haben dasselbe Ziel wie vorher


Class Introduction

Analyse Bestimmung der Menge lookup(C), der Menge der geerbten

Methoden einer Klasse C, deren Quelle sich geändert hat Hierarchie H=(C,) mit einer Menge C von Klassen C

und einer darauf definierten Relation " "( B A gdw. B ist Subklasse von A)

Menge der Introductions einer Klasse C: Ints(C) members(C) = Menge der in C (re-)definierten

Methoden

A

B


n

n

n

n

Class Introduction

Analyse Algorithmus zur Bestimmung der Menge lookup(C)

mit angepaßter Breitensuche (BFS)

Input: Hierarchie H=(C,), C C: Ints(C)Output: C C: lookup(C)

queue = {max()}while queue do

C = remove(queue)lookup(C) = (lookup(father(C)) - members(C))

Ints(C)D: D C do: add D to queue

A

C

B

B.nB.m

B.nB.m

B.nB.m

G D

FE

F.nB.m

G.nB.m

B.nB.m

A.n


Class Introduction

Bemerkung lookup(father(root)) := in Java ist Hierarchie immer ein Baum mit max. Element

java.lang.Object

Fortsetzung die Menge lookup wird im nächsten Schritt erweitert um die

Änderungen, die aus Modifikationen der Vererbungshierarchie entstehen

danach folgt die Auswertung an Hand von Test-Treibern


Änderung der Klassenhierarchie

Beschreibung Verschiebung von Klassen in der Vererbungshierarchie (nach

unten) mit all ihren Subklassen nur zu Geschwistern und deren Subklassen erlaubt

mögliche Interferenz "Binding Interference":

Auswirkungen auf die Ausführung geerbter Methoden

"instanceof": ClassCastExceptions werden plötzlich nicht mehr geworfen Abfragen der Form "if B instanceof A" ändern ihren Wert gesamter Programmablauf kann betroffen sein


instanceof Interference:D instanceof G = true

Binding Interference:D.n

Änderung derKlassenhierarchie Beispiel

aspect O { declare parents: D extends G;}

A

C

B

A.nB.m

A.nB.m

A.nB.m

G D

FE F.nB.m

G.nB.m

A.nB.m

A.n A.nA

C

B

A.nB.m

G.nB.m

A.nB.m

G

D

F

E

F.nB.m

G.nB.m

A.nB.m

Aspect O


Änderung der Klassenhierarchie Analyse

erneut muß nach Anwendung des Aspekts das "No-Interference"-Kriterium gelten:

aber: nur notwendige, nicht hinreichende Bedingung zusätzlich müßte gelten, daß alle Statements, die das Prädikat

instanceof enthalten, zu demselben Wert ausgewertet werden

alle möglichen Aufrufe haben dasselbe Ziel wie vorher



um dies zu berechnen, müßten alle Referenzierungen bekannt sein Entscheidung, zu welcher Klasse ein Objekt zur Laufzeit gehört, ist

zur Compilezeit nicht möglich (unentscheidbares Problem) stattdessen Angabe von Obermengen von Klassen eines Objektes

(zu welchen Klassen könnte das Objekt zur Laufzeit gehören?) um gleiches Verhalten garantieren zu können, müßten die

berechneten Obermengen vor und nach der Anwendung des Aspekts genau ein und dasselbe Element enthalten

ansonsten müßte man von einer Änderung des Verhaltens des Systems ausgehen



ohne instanceof: Prüfung des "No-Interference"-Kriteriums ausreichend

kritisch: Aufrufe von Methoden, die zwischen der alten und der neuen Superklasse (einschließlich) (re-)definiert sind

neue Hierarchie H'=(C,') Mod(H) = Modifikationen der

Hierarchie

B

G.nB.m

G

D

F

G.nB.m

A.nB.m



Prüfung für die verschobene Klasse:

Input: Hierarchie H'=(C,'), Mod(H), lookup(C)Output: C C: lookup(C) (ggf. erweitert)

1. Bestimme die Menge D der Klassen, die von der Modifikation der Hierarchie (Mod(H)) betroffen sind2. d D: berechne die Menge der Zwischenklassen IC zwischen d und der alten Superklasse 3. Für jede Methode m bekannt in d:

Prüfe, ob sie von einer Klasse aus IC geerbt wirdFalls ja, hat sich das Verhalten der Methode potentiell verändert-> n wird zu lookup(d) hinzugefügt-> alle Subklassen s von d, die m nicht

redefinieren, erhalten eine Erweiterungvon lookup(s) um m (bis zur ersten, die m redefiniert)

A

C

B

A.nB.m

G.nB.m

A.nB.m

G

D

F

E

F.nB.m

G.nB.m

A.nB.m

A.n


Auswirkungsanalyse

vorhanden sind: Mengen lookup(C) für alle Klassen C Menge von Test-Treibern T = {t1, ... , tn} des Basis-Systems

ti rufen Untermengen von Methoden aus Klassen der Hierarchie H auf, i = 1, ... , n

Bestimmung der Test-Treiber, die nach der Anwendung des Aspekts erneut laufen gelassen werden müssen und deren Ergebnisse überprüft werden müssen

an Hand des Aufrufgraphen von ti wird geprüft, ob eine Methode aus lookup(C) einer Klasse C aufgerufen wird falls ja, muß der Test-Treiber nach Anwendung des Aspekts erneut

durchlaufen und sein Ergebnis überprüft werden


Auswirkungsanalyse

Beispiel:

Class T1 { public static void main(String[] args) {

F f = new F();f.m(); // ruft B.m()f.n(); // ruft F.n()

}}

T1.main

F

B.m

F.n

F

A

C

B

A.nB.m

G.nB.m

A.nB.m

G

D

F

E

F.nB.m

G.nB.m

A.nB.m

A.n


Auswirkungsanalyse

um den Aufrufgraphen entwickeln zu können, benötigt man Wissen über den Objekttypen von jedem rufenden Objekt zur Laufzeit (also über die Klasse, der das rufende Objekt angehört)

diese Berechnung ist wiederum unentscheidbar stattdessen Approximation durch Mengen von möglichen, im

Test-Treiber referenzierten Objekttypen ruft ein möglicher Objekttyp einer Menge eine geänderte

Methode (aus lookup) auf, so muß der Treiber markiert werden (als "zu wiederholen")


Auswirkungsanalyse

nach erfolgter Auswirkungsanalyse erhält man: eine Menge von Introductions und Änderungen der

Vererbungshierarchie, die keine Auswirkung auf das Verhalten des Systems haben (allerdings nur in Bezug auf die geprüften Test-Treiber) - sie können in das System integriert werden

eine Untermenge der Test-Treiber (die, die erneut durchlaufen werden müssen)

diese Informationen können vom Programmierer genutzt werden, ungewollte Seiteneffekte zu erkennen und zu vermeiden (oder auch gewollte zu überprüfen)


Beispiel

class A { void n() { print("A.n()"); }} class B extends A { void m() { print("B.m()"); }}class C extends B { public void x() { print("C.x()"); }} class D extends B { public void y() { print("D.y()"); } public void x() { print("D.x()"); }}class E extends C {} class F extends D { void n() { print("F.n()"); }}class G extends B { void n() { print("G.n()"); }}interface I { void x(); void y();}

aspect M { declare parents: C implements I;declare parents: D implements I;public void I.y() { print("I.y()"); }}

aspect N { void B.n() { print("B.n()"); }}

aspect O { declare parents: D extends G;}

Basiscode Aspektcode


Beispiel

Interface Introduction Warnungen für

C.y und E.y

A

C

B

B.nB.m

G.nB.m

B.nB.m

G

D

F

E

F.nB.m

G.nB.m

B.nB.m

A.n

C.x

D.xD.y

C.x

D.xD.y

I.y

I.y

I.y

I


Beispiel

Class Introductionlookup(B) = {n}

lookup(C) = {n}

lookup(E) = {n}

A

C

B

B.nB.m

G.nB.m

B.nB.m

G

D

F

E

F.nB.m

G.nB.m

B.nB.m

A.n

C.x

D.xD.y

C.x

D.xD.y

I.y

I.y

I.y

I


Beispiel

Declare Parentslookup(B) = {n}

lookup(C) = {n}

lookup(E) = {n}

lookup(D) = {n}

A

C

B

B.nB.m

G.nB.m

B.nB.m

G

D

F

E

F.nB.m

G.nB.m

B.nB.m

A.n

C.x

D.xD.y

C.x

D.xD.y

I.y

I.y

I.y

I


Beispiel

Auswirkungsanalyse

Class T1 { public static void main(String[] args) {

F f = new F();f.m(); // ruft B.m()f.n(); // ruft F.n()

}}Class T2 { public static void main(String[] args) {

B b = new B();b.n(); // ruft B.n()

} // lookup !!}Class T3 { public static void main(String[] args) {

G d;if (args.length != 0) d = new D();else d = new G();d.n(); // ruft G.n()

} // Rufender:} // D oder G

T1.main

F

B.m

F.n

F

T2.main B B.n

T3.mainD oder G

G.n


Auswirkungsanalyselookup(B) = {n}

lookup(C) = {n}

lookup(E) = {n}

lookup(D) = {n}

"zu wiederholen" = {T2, T3}

Beispiel

T1.main

F

B.m

F.n

F

T2.main B B.n

T3.mainD oder G

G.n


Zusammenfassung / Ausblick

Aspekt <-> Basiscode Was sind Interferenzen? Wodurch treten sie auf? Algorithmus zum Aufspüren von Interferenzen an Hand der Ergebnisse aus den Wiederholungsläufen der

markierten Test-Treiber muß der Entwickler entscheiden, ob die gefundenen Auswirkungen gewollt sind oder nicht

Aspekt <-> Aspekt Advices (zusätzliche Funktionen, die zu Join-Points eingewoben

werden) mehrere, die an gleicher Stelle angreifen

Advices/Introductions Überschneidungen


Literatur

Maximilian Störzer, Jens Krinke: Interference Analysis for AspectJ (2003)

universität bonn, seminar component and aspect engineering ws 2003/2004, dirk schiele 1...

Documents

class c

y aspect

aspect engineering ws

void x void y

class d

class b

y folie

void n