Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 1 Aspekt-Interferenzen Seminar Component and Aspect Engineering Uni.

Präsentation zum Thema: "Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 1 Aspekt-Interferenzen Seminar Component and Aspect Engineering Uni."—  Präsentation transkript:

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

2 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 2 Inhaltsübersicht l Motivation uWiederholung AOP uWas sind Interferenzen? uWodurch entstehen sie? l Analyse an Hand zentraler Features von AspectJ uInterface Introduction uClass Introduction uÄnderung der Klassenhierarchie uAuswirkungsanalyse uBeispiel l Zusammenfassung / Ausblick

3 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 3 Motivation - Wozu AOP? l AOP (Aspect Oriented Programming) uZiel: 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

4 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 4 Motivation - Wie macht's AspectJ? l AspectJ uJava-Erweiterung uAspekte und Funktionen werden getrennt implementiert uVerbindung à Join Points (Methodennamen, Ausführungszeitpunkt) à Klassennamen uAspect-Weaver webt die Aspekte zur Compilezeit (oder auch Lade- oder Laufzeit) in das Basissystem ein

5 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 5 Motivation - Interferenzen l Was sind Interferenzen? ugewollte oder ungewollte Einflüsse von Aspekten (z.B. falsche Methodenaufrufe) uÄnderung des Verhaltens des gesamten Systems l Wodurch entstehen sie? uInterface Introduction à Einfügung von zusätzlichen Interface-Implementierungen uClass Introduction à Einfügung von zusätzlichen Feldern/Methoden in Klassen u"Declare-Parents" à Änderungen an der Vererbungshierarchie uAdvice à Ausführung zusätzlicher Funktionen uProblem: à geteilte Implementierung von Aspekten und Funktionen à Änderungen sind nicht direkt im Sourcecode sichtbar

6 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 6 Motivation - Beispiel l 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 B.n A C B A.n B.n

7 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 7 Analyse an Hand von AspectJ-Features l Interface Introduction uBeschreibung umögliche Interferenzen uAnalysevorgehen l Class Introduction uBeschreibung umögliche Interferenzen uAnalysevorgehen l Änderung der (Vererbungs-) Klassenhierarchie uBeschreibung umögliche Interferenzen uAnalysevorgehen Output:Warnungen, Menge von unbedenklichen Aspekt-Operationen, Menge von zu wiederholenden Test-Treibern Input: Basissystem, Aspekt-Code, Menge von Test-Treibern Interface Introd. Auswirkungsanalyse Declare-Parents Class Introduction

8 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 8 Interface Introduction l Beschreibung unachträgliche / zusätzliche Implementierungen von Schnittstellen uZiel: Default-Methoden à zur Arbeitserleichterung bei der Programmierung à um ggf. Mehrfachvererbung abbilden zu können l mögliche Interferenz: uvergessene (Re-)Definitionen in implementierenden Klassen l Compilerwarnung wäre sinnvoll

9 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 9 A B C C.xD.x D.y C.x GD FE D.x D.y Interface Introduction l 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 aspect M { declare parents: C implements I; declare parents: D implements I; public void I.y() { print("I.y()"); } } IA B C C.xD.x D.y C.x GD FE D.x D.y

10 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 10 l Analyse ubestimme Menge der Interfaces aus Aspekt A: I def ubestimme Menge der Klassen, die ein Interface aus I def implementieren: C l def ubestimme die Klassen aus C l def, die nicht alle Methoden des entsprechenden Interfaces erneut definieren l Programmierer muß jeweils prüfen, ob die Methoden verwendet werden sollen Interface Introduction C C.xD.x D.y C.x GD A B FE D.x D.y I I.y

11 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 11 Class Introduction l Beschreibung uzusätzliche Felder / Methoden zu Klassen hinzuzufügen uZiel: Erweiterung der Funktionalität (z.B. Persistenz) l mögliche Interferenz: "Binding Interference" uOOP -> "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

12 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 12 Class Introduction l Beispiel: aspect N { void B.n() { print("B.n()"); } } A B A.n B.m A.n B.m A.n B.m GD F F.n B.m G.n B.m A.n B.m A.n B.n B.m C E

13 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 13 Class Introduction l Bemerkungen udurch die getrennte Implementierung sind die Interferenzen im Basiscode nicht zu erkennen ubeide Teile, Basiscode und Aspektcode, müssen parallel betrachtet werden uSemantik des Systems ändert sich ggf. extrem uJava-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

14 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 14 Class Introduction l Analyse unach Anwendung des Aspekts muß das "No-Interference"-Kriterium gelten: uum mögliche semantische Änderungen aufzudecken udazu 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

15 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 15 Class Introduction l Analyse uBestimmung 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) uMenge der Introductions einer Klasse C: Ints(C) umembers(C) = Menge der in C (re-)definierten Methoden A B

16 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 16 n n n n Class Introduction l Analyse uAlgorithmus 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.n B.m B.n B.m B.n B.m GD FE F.n B.m G.n B.m B.n B.m A.n

17 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 17 Class Introduction l Bemerkung u lookup(father(root)) := uin Java ist Hierarchie immer ein Baum mit max. Element java.lang.Object l Fortsetzung udie Menge lookup wird im nächsten Schritt erweitert um die Änderungen, die aus Modifikationen der Vererbungshierarchie entstehen udanach folgt die Auswertung an Hand von Test-Treibern

18 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 18 Änderung der Klassenhierarchie l Beschreibung uVerschiebung von Klassen in der Vererbungshierarchie (nach unten) umit all ihren Subklassen unur zu Geschwistern und deren Subklassen erlaubt l mögliche Interferenz u"Binding Interference": à Auswirkungen auf die Ausführung geerbter Methoden u"instanceof": à ClassCastExceptions werden plötzlich nicht mehr geworfen à Abfragen der Form "if B instanceof A" ändern ihren Wert à gesamter Programmablauf kann betroffen sein

19 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 19 instanceof Interference: D instanceof G = true Binding Interference: D.n Änderung der Klassenhierarchie l Beispiel aspect O { declare parents: D extends G; } A C B A.n B.m A.n B.m A.n B.m GD FE F.n B.m G.n B.m A.n B.m A.n A C B B.m G.n B.m A.n B.m G D F E F.n B.m G.n B.m A.n B.m Aspect O

20 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 20 Änderung der Klassenhierarchie l Analyse uerneut muß nach Anwendung des Aspekts das "No-Interference"- Kriterium gelten: uaber: nur notwendige, nicht hinreichende Bedingung uzusä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

21 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 21 Änderung der Klassenhierarchie l Analyse uum dies zu berechnen, müßten alle Referenzierungen bekannt sein uEntscheidung, zu welcher Klasse ein Objekt zur Laufzeit gehört, ist zur Compilezeit nicht möglich (unentscheidbares Problem) ustattdessen Angabe von Obermengen von Klassen eines Objektes (zu welchen Klassen könnte das Objekt zur Laufzeit gehören?) uum gleiches Verhalten garantieren zu können, müßten die berechneten Obermengen vor und nach der Anwendung des Aspekts genau ein und dasselbe Element enthalten uansonsten müßte man von einer Änderung des Verhaltens des Systems ausgehen

22 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 22 Änderung der Klassenhierarchie l Analyse uohne instanceof: Prüfung des "No- Interference"-Kriteriums ausreichend ukritisch: Aufrufe von Methoden, die zwischen der alten und der neuen Superklasse (einschließlich) (re-)definiert sind neue Hierarchie H'=(C, ') uMod(H) = Modifikationen der Hierarchie B G.n B.m G D F G.n B.m A.n B.m

23 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 23 Änderung der Klassenhierarchie l Analyse uPrü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 sind 2. 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 wird Falls 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 Erweiterung von lookup(s) um m (bis zur ersten, die m redefiniert) A C B A.n B.m G.n B.m A.n B.m G D F E F.n B.m G.n B.m A.n B.m A.n

24 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 24 Auswirkungsanalyse l vorhanden sind: uMengen lookup(C) für alle Klassen C Menge von Test-Treibern T = {t 1,..., t n } des Basis-Systems t i rufen Untermengen von Methoden aus Klassen der Hierarchie H auf, i = 1,..., n l Bestimmung der Test-Treiber, die nach der Anwendung des Aspekts erneut laufen gelassen werden müssen und deren Ergebnisse überprüft werden müssen l an Hand des Aufrufgraphen von t i wird geprüft, ob eine Methode aus lookup(C) einer Klasse C aufgerufen wird ufalls ja, muß der Test-Treiber nach Anwendung des Aspekts erneut durchlaufen und sein Ergebnis überprüft werden

25 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 25 Auswirkungsanalyse l 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.n B.m G.n B.m A.n B.m G D F E F.n B.m G.n B.m A.n B.m A.n

26 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 26 Auswirkungsanalyse l 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) l diese Berechnung ist wiederum unentscheidbar l stattdessen Approximation durch Mengen von möglichen, im Test-Treiber referenzierten Objekttypen l ruft ein möglicher Objekttyp einer Menge eine geänderte Methode (aus lookup) auf, so muß der Treiber markiert werden (als "zu wiederholen")

27 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 27 Auswirkungsanalyse l nach erfolgter Auswirkungsanalyse erhält man: ueine 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 ueine Untermenge der Test-Treiber (die, die erneut durchlaufen werden müssen) l diese Informationen können vom Programmierer genutzt werden, ungewollte Seiteneffekte zu erkennen und zu vermeiden (oder auch gewollte zu überprüfen)

28 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 28 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

29 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 29 Beispiel l Interface Introduction uWarnungen für C.y und E.y A C B B.n B.m G.n B.m B.n B.m G D F E F.n B.m G.n B.m B.n B.m A.n C.x D.x D.y C.x D.x D.y I.y I

30 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 30 Beispiel l Class Introduction lookup(B) = {n} lookup(C) = {n} lookup(E) = {n} A C B B.n B.m G.n B.m B.n B.m G D F E F.n B.m G.n B.m B.n B.m A.n C.x D.x D.y C.x D.x D.y I.y I

31 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 31 Beispiel l Declare Parents lookup(B) = {n} lookup(C) = {n} lookup(E) = {n} lookup(D) = {n} A C B B.n B.m G.n B.m B.n B.m G D F E F.n B.m G.n B.m B.n B.m A.n C.x D.x D.y C.x D.x D.y I.y I

32 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 32 Beispiel l 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.main D oder G G.n

33 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 33 l Auswirkungsanalyse lookup(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.main D oder G G.n

34 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 34 Zusammenfassung / Ausblick l Aspekt Basiscode uWas sind Interferenzen? uWodurch treten sie auf? uAlgorithmus zum Aufspüren von Interferenzen uan Hand der Ergebnisse aus den Wiederholungsläufen der markierten Test-Treiber muß der Entwickler entscheiden, ob die gefundenen Auswirkungen gewollt sind oder nicht l Aspekt Aspekt uAdvices (zusätzliche Funktionen, die zu Join-Points eingewoben werden) à mehrere, die an gleicher Stelle angreifen uAdvices/Introductions à Überschneidungen

35 Universität Bonn, Seminar Component and Aspect Engineering WS 2003/2004, Dirk Schiele 35 Literatur l Maximilian Störzer, Jens Krinke: Interference Analysis for AspectJ (2003)