Aspekte in der Softwareentwicklung Stefan Jähnichen, Stephan Herrmann, Katharina Mehner Ringvorlesung „Modellbasierte Softwareentwicklung“ SoSe 2004, Humboldt Universität

Wartungsproblematik Illustration und Beispiel --------------------------- Aufhänger Illustration Mikado: Wollen Sie dieses System warten? Beispiele aus der Praxis erzählen Hintergrund-Info ------------------ Langlebige Software: Zerfall von Strukturen, Zerstörte Modularität Verschiedenste Gründe: Fokus auf SPRACHEN (Zusammenhang Säulen der Softwaretechnik) Zwei Argumentationsebenen: 1. Probleme der Softwareentwicklung, insbesondere Inkrementalität und Wartung/Evolution 2.Teilweise auf Probleme der verwendeten Sprachen zurückführen: Paradigmenbruch und fehlende Integration Sprachen: Beherrschung von Komplexität Sichten und Integration Ziele der Softwareentwicklung: Wiederverwendung aller Artefakte und Aktivitäten, Komponenten

AspectBrowser Anknüpfen an Mikado: Genaue Analyse der zerstörten Modularität auf Ebene des Codes Screenshot - Einfärbung von Code, der zu einer gemeinsamen Anforderung gehört - Beispiel Selbstanwendung auf den AspectBrowser Phänomen - querbezüglichen Anforderungen „crosscutting“ mit - Tangling = Vermischung verschiedener Anforderung in einem Modul - Scattering = Verstreuung einer Anforderung über ein Modulgeflecht Problemklasse der querschneidenen „Aspekte“ - Logging, Sicherheit, Persistenz AspectBrowser [UCSD Software Evolution Lab] http://www.cs.ucsd.edu/users/wgg/Software/AB/ ZIEL: Auffinden und Visualisieren von crosscutting concerns ANNAHME: Codestücke, die zu einer Anforderung/Concern gehören, sind textuell verwandt: Identifier, Library Aufrufe, Redundanter Code TECHNIK: Analyse textueller Patterns, Heuristiken zum Definieren brauchbarer Patterns, Visualisierungs-Metapher stammt aus dem Tool Seesoft, dass Codezeilen anhand von Historie und Testergebnissen einfärbt. 1. Editor mit Code-Highlighting (ohne Abbildung) 2. Visualisierungstool Nebulous (Screenshot) Hauptfenster (rechts): Reihe mit je ein Fenster pro Datei, Innerhalb Fenster eine Pixelzeile pro Zeile Code Auswahlfenster (oberhalb): Verkleinerte Liste von Hauptfenstern Aspekt-Index (linker Rand): Name und Farbgebung eines Concerns Roter Punkt: Cursor und Cursor-Historie

Crosscutting Concerns Problemanalyse Tangling: Vermischung verschiedener Anforderung in einem Modul Schwierig, Modul zu ändern Scattering: Verstreuung einer Anforderung über ein Modulgeflecht Schwierig, Aspekt zu ändern Problemklasse Aspekte Crosscutting Concerns Logging Synchronisation IT-Sicherheit Persistenz Caching Profiling Verteilung ...

Aspektorientierte Programmierung Erweiterung objektorientierter Programmier- sprachen Trennung von Aspekt und Basisfunktionalität Aspektmodule für querschneidende Anforderung Für gerade beschriebene Klasse der querbezüglichen Anforderungen Lösungsansatz Aspektorientierung „Kunst Aufräumen“ -> Software Aufräumen?? ©Ursus Wehrli Problem: Bezüge sind nicht mehr zu erkennen Integration Weben: Integration von Klassen und Aspekten

Beispiel Sicherheit Basisfunktionalität: Authentisierung: Nur angemeldete Benutzer dürfen Operationen auf Konten ausführen Authorisierung: Unterschiedliche Benutzerrollen haben verschiedene Zugriffsrechte für Konten Owner-Rolle: Objekt vom Typ User, das als Besitzer des Kontos eingetragen ist, auf dem Operation ausgeführt wird Employee-Rolle: Objekt vom Typ Employee User-Rollen: beliebige Java-Objekte, die Referenz auf Account haben getBalance debit credit transfer Owner x Employee o User

Authentisierung in AspectJ public aspect Authentication { pointcut requireAuthentication() : execution(public * Account.* (..)); before() : requireAuthentication() if (LoginContext.getInstance().getUser() == null) authenticateUser(); //Benutzer anmelden } // Benutzer wird an anderer Stelle wieder abgemeldet Prädikat über Ausführungspunkte Ausführungen einer Methode „bei welchen Ausführungen“ „vor“ diesen Ausführungen Zusätzlich auszuführender Code Authentication betrifft alle 4 Methoden der Klasse Account (und zukünftige Methoden), Elegant durch Accout.* beschrieben. Pointcut = Punkte im Kontrollfluss Ein Pointcut fasst eine solche Methodenmenge deklarativ zusammen. Zur Laufzeit erfasst der Pointcut konkrete Methodenausführungen (auch Join Points genannt). Der auszuführende Code wird auch als Advice bezeichnet. Erst hier ist es möglich, zu sagen, ob der Advice vor oder nach der Ausführung aufgerufen wird.

Authorisierung in AspectJ Nicht, wenn debit aus einer anderen Methode von Account aufgerufen wurde public aspect Authorization { declare precedence : Authentication, Authorization; //Authorisierung verwendet Ergebnis der Authentisierung pointcut requireOwner(Account acnt) : execution(public * Account.debit(..)) && !cflowbelow(execution(public * Account.*(..))) && target(acnt); before(Account acnt) : requireOwner(acnt) System.out.println("RequireOwner"); if (!LoginContext.getInstance().getUser().equals(acnt.getOwner())) throw new AccessDeniedException("No valid user logged in!"); } Reihenfolge Parameter Bindung Owner Überprüfung Fazit: Expliziter Umgang mit Ausführungspunkten (auch geschachtelt). Nur Owner darf auf debit zugreifen. Ausnahme: debit wird von anderen Methoden z.B. transfer aufgerufen. Declare precedence: Reihenfolge aber keine Vorrausetzung!!! cflowbelow(Filter)ist wahr, wenn die passenden Methoden im Callstack vorkommt, public aspect Authorization { declare precedence : Authentication, Authorization; pointcut requireOwner(Account acnt) : execution(public * Account.debit(..)) && !cflowbelow(execution(public * Account.*(..))) && target(acnt); pointcut requireOwnerOrEmployee(Account acnt) : (execution(public * Account.transfer(..)) || execution(public * Account.getBalance())) before(Account acnt) : requireOwner(acnt) System.out.println("RequireOwner"); if (!LoginContext.getInstance().getUser().equals(acnt.getOwner())) throw new AccessDeniedException("No valid user logged in!"); } before(Account acnt) : requireOwnerOrEmployee(acnt) System.out.println("RequireOwnerOrEmployee"); User actUser = LoginContext.getInstance().getUser(); if (!(actUser.equals(acnt.getOwner()) || (actUser instanceof Employee)))

Integration Compilezeit Laufzeit Varianten Statisches Weben (engl. Weaving) Übersetzen der Aspekte nach Java Transformation der Basisklassen Laufzeit Ausführung auf einer Standard JVM Varianten Dynamisches Weben zur Laufzeit Basisfunktionalität Authentisierung Authorisierung Joinpoints als Pfeile

Aspekt-Strukturen Aspekt Wenig Zusammenhang Wirksam an vielen Stellen Geeignet für eine bestimmte Klasse von Anforderungen Basisklassen müssen nicht geändert werden

Defizite Keine Ausdrucksmöglichkeit für Abhängigkeiten Aspekt setzt anderen Aspekt voraus Aspekte schliessen sich gegenseitig aus Keine Unterstützung für Stark strukturierte Anforderungen Komplexe Workflows Kollaborationen Wiederverwendung von Aspekten Aspektkomposition Allgemeinere Lösung Symmetrie von Aspekten und Klassen Komposition Vererbung Instanziierung Argumentation über Sichten

Separation of Concerns Separation of Concerns: soviele Konzepte sind schon da, sie müssen nur einheitlich für alle Phasen der Softwareentwicklung einsetzbar gemacht werden. Das System selbst ist und bleibt komplex, Aber Sichten auf das System erlauben eine Zerlegung dieser Komplexitaet .. Hat sich schon vielfach bewaehrt (Übergang nächste Folie) Komplexe Relationen beherrschen Getrennte Definition von Sichten

Sichten als Sprachkonzept Modularisierung der Anforderungen nach Sichten Funktional (z.B. OOA Use Cases, Klassendiagramm, …) Struktur und Verhalten Nicht-funktional Spezielle Sicht auf Struktur und Verhalten Modularisierung im Design nach Sichten Nach Form Struktur, Dynamik, Funktion [OMT] Nach Inhalt Kollaborationsbasiertes OO-Design mit Rollen [Catalysis, OORAM] Objektorientierte Programmiersprachen Nach Form (Klassen = Einheit von Daten und Methoden) Fokus auf Algorithmik [Diese und die nächsten beiden Folien könnten noch etwas komprimiert werden] Sichten sind nicht neu in der SWT Anforderungen: Sichten = Viewpoints Programmiersprachen: hier sieht es noch am duennsten aus. Who-is-who: OMT Rumbaugh, Catalysis D‘Souza OORAM Reenskaug Viewpoints Finkelstein Beispiele Anforderung: NFR: Sicherheit: Authentisierung, Autorisierung Constraint (NFR, die dem System nicht hinzugefügt werden kann): Response Time

Nahtlose Entwicklung? Paradigmen und Medienbrüche Übergänge erfolgen nur als Gesamtheit schlecht erweiterbar schlecht umkehrbar Erweiterungen zerstören Strukturierung Durch OO nur teilweise nahtloser Übergang OOD-> OOP „nahtlos“, OOA->OOD problematisch OOA: Use Cases und Aktivitätsdiagramme getrennt von Objekten OOD: Objektorientierte Methoden Im Allgemeinen keine Modularisierung von Kollaborationen In jeder Phase existieren verschiedene Sichten. Wie können komplexe Modelle mit Sichten von einer Phase in die andere Übertragen werden? Was ist das Problem? Medienbrüche an sich sind kein Argument für schlechte Anpassbarkeit, nur die daraus resultierenden Probleme. Medienbrüche können Paradigmenbrüche sein. Dann kann es sein, dass Medienbrüche implizieren Strukturierungsbrüche = Modularisierungsbrüche, d.h. bei Übergang erfolgt Änderung der Modulstruktur Begriff Strukturierung/Modularisierung. (Strukturierung hier nicht im Sinne von Struktur vs. Verhalten) One-Way = Übergang kann nur in einer Richtung erfolgen. Änderungen lassen sich nicht zurücktransformieren. One-Shot = einmalige Erzeugung einer Gesamtlösung bei einem Übergang, die insbesondere nicht nachträglich erweitert werden können. D.h. der Übergang kann immer nur als Ganzes vollzogen werden.

Herausforderung Durchlässigkeit erreichen durch ein einheitliches Paradigma Übergänge zwischen Modellen müssen durchlässig sein Nahtloser Übergang zwischen Artefakten verschiedener Aktivitäten Inkrementell Bidirektional Beliebig oft Analoge Strukturierung/Modularisierung der Artefakte Querbezüge und Sichten-Integration innerhalb eines Modells Möglichkeit, um Querbezüge zu beschreiben Vollständigkeit Paradigma der Sichten soll sich in allen Modellen wiederfinden „Traditionelle Aspekte“ Kollaborationen Herausforderung 1: Sichtenintegration Wird verfeinert in 2 Teil-Herausforderungen: Crosscutting Kollaborationen Herausforderung 2: Paradigmendurchlässigkeit Lässt sich durch Auswahl von vorherrschenden Paradigmen für alle Dokumente beantworten

Komplexe Aspekte Beispiel: Geschäftsfälle Konventionelle Lösung Flugbuchung Bonusprogramm Konventionelle Lösung Jede Buchungsoperation muß Buchung durchführen Bonusmeilen gutschreiben Problem Geschäftsfälle sind nicht unabhängig Kaskaden von Fallunterscheidungen Welche Fluggesellschaft? Passagier registriert? Welcher Status? Wiederverwendung?? Wartung?? Ab hier: eine Art von Sichten/Aspekten die z.B. mit AspectJ schlecht unterstützt werden. Verständnis??

Flugbuchung+-bonus ist Mikado Software aufräumen Lösung: Programmiermodell Object Teams Folie noch nicht fertig -- bzw. fertige F. versehentlich gelöscht ;-/ Überlagerung Mikado mit einem Entscheidungs-/Kontrollflussgraphen der Operation Flug-Buchen. Aussage: Buchung und Bonusmeilen sind so fragil miteinander verknüpft wie das Mikado.. Einblendung: Unsere Lösung: Object Teams. Hier könnte die Liste der Konzepte als Zwischengliederung eingefügt werden: Kollaborationsmodule A-posteriori Integration Flexible Kopplung Bidirektionale Schnittstellen Forwarding Aspekt-Bindung Dynamische Aktivierung Teamvererbung

Kollaborationsmodule (1) FlightBooking Gewöhnliches Paket Abgeschlossen Lauffähig Soll nicht verändert werden!

Kollaborationsmodule (2) Bonus Unvollständiges Paket Enthält verschiedene Rollen Interaktion zwischen Rollen Kollaboration kann instanziiert werden Team! public team class Bonus { class Subscriber { ... } class BonusItem { ... } private int accumulator; } Unvollständig: abstrakt (Paket Bonus und Klasse BonusItem) (erkennbar an Kursivschrift) Kollaboration instanziieren: ist normale Klasse mit Attributen (z.B. accumulator) und Methoden (put/take) team: neues Schlüsselwort

A-Posteriori-Integration Zerlegen ist einfach, aber ... Konnektor Weitgehend deklarativ Sonderfälle imperativ ausprogrammieren Drei Ebenen der Bindung: Klassen Methoden Parameter Modul FlightBonus dient nur dazu, das Konzept Bonus auf FlightBooking anzuwenden Konzeptionell: Konnektor, technisch: Team, d.h. Konnektor ist eine spezielle Nutzungsform von teams. Imperativ: bsp. Implementierung der Methode calculateCredit nach der policy der jeweiligen Fluggesellschaft Bindungen (im Folgenden genauer beschrieben): Klassen (Rolle->Basis): Subscriber -> Passenger BonusItem -> Segment Methoden siehe spaeter Parameter (weggelassen)

Flexible Kopplung Rolle-Basis-Beziehung „playedBy“ Unabhängigkeit Basis „ignorant“ Beliebige Anzahl Rollen pro Basis Integration Rolle + Basis = Konzeptionelle Einheit Objektbasierte Vererbung Realisiert u.a. durch unsichtbaren Link RoleBasis Rollen sind Aspekte der Basis Vergleiche auch: Entwurfsmuster Decorator! class Subscriber playedBy Passenger { ... } class BonusItem playedBy Segment { ... } „Ignoranz“ ist eins der Grundprinzipien der AOP: Entwickler eines Aspektes/der Basisfunktionalität muß andere Aspekte ignorieren können (Kopf frei behalten...) Zitat Bob Filmann: „AOP is obliviousness and quantification“ („Vergesslichkeit...“) Decorator: anreichern eines Objektes um zusätzliche Attribute und Methode, ohne daß ursprünglicher Client dies bemerken muß. Rollen reichern ihre Basis an! playedBy weiteres Schlüsselwort, gewisse Analogie: extends = Klassenvererbung playedBy = Objektvererbung, Beziehung wird erst zur Laufzeit hergestellt. Daraus resultiert die Flexibilität der Kopplung.

Bidirektionale Schnittstelle Analogie CORBA Components: expected/provided interface Zwei Richtungen von Methodenbindungen Aus Sicht der Rolle (Basis bleibt ignorant) Vollständige Interaktion zwischen Paketen Wo ruft das Team Basisfunktionalität auf? Wo läßt sich das Team aus der Basis heraus aufrufen? Nach der strukturellen Integration zw. Klassen nun die Methodenbindungen. Beispiele auf den naechsten beiden Folien

Forwarding: Callout Rolle leitet Aufrufe an Basis weiter class BonusItem playedBy Segment { getPoints -> getPrice; } Empfänger der Nachricht bleibt implizit Rolle-Basis-Link nicht direkt zugreifbar Vermeidung von Inkonsistenzen Parametermappings Falls Signaturen nicht passen Deklarative Abbildung von Parametern und Resultat Kann einfache Berechnungen enthalten Aufrufe weiterleiten ist gleichbedeutend mit objektbasierter Vererbung: Rolle kann features der Basis benutzen Parametermappings hier nicht gezeigt.. Wichtig eventuell: nahtlose Integration von deklarativem und imperativen Anteil!

Aspektbindung: Callin Einflechten von Triggern in die Basis class BonusItem playedBy Segment { collectCredit() <- after book; } Effekt: Nach jeder Ausführung von Segment.book() wird BonusItem.collectCredit() aufgerufen An welchem Objekt? Implizites Aufsuchen „des richtigen“ Rollenobjektes. Mechanismus „lifting“ Vollständig automatisiert Lifting erklaeren wuerde hier zu weit fuehren (die “Technik unter der Haube” – zentrales Konzept, warum in OT die getrennten Objekte Rolle+Basis reibungslos funktionieren, wo verschiedene andere Ansätze an schwieriger Handhabung scheiterten.) Fazit: callin Bindungen sind ähnlich zum Aspektweben in AspectJ ABER verbesserte Symmetrie zu callout beide zusammen ergeben die Interaktion zw. einem Team und der adaptierten Basis.

Dynamische Aktivierung Teaminstanzen Repräsentieren Bonusprogramme versch. Fluggesellschaften Einzeln aktivieren/deaktivieren Passagiere einzeln bei Teaminstanzen registrieren Aktivierung bedeutet Einschalten aller callin-Bindungen des Teams Deaktiviertes Team ist als Aspekt wirkungslos Dynamische Aspekte werden von vielen Autoren gefordert, Lösungen sind z.T. sehr mühsam. Vorteil OT: nicht einzelne Rollen aktivieren sondern gesamtes Team.

Teamvererbung Konsistente Verfeinerung einer Kollaboration Virtuelle Klassen, Class Overriding, Family Polymorphism (typsichere Kovarianz!) Kann als Framework-Vererbung eingesetzt werden Verfeinerung kann als Konnektor fungieren Beliebige Mischformen: Hinzufügen von Implementierung Hinzufügen von Bindungen Neue Form von Wiederverwendung Beispiel: FlightBonusVIP als Spezialisierung von FlightBonus Komplette Kollaboration wird geerbt (Rollen und ihre Interaktionen) Gezielte Anpassungen im Team und/oder seinen Rollen möglich Virtuelle Klassen etc.: in der wissensch. OO-community (bes. ECOOP) heiß diskutierte Themen. s.o.: Konnektor als spezifische Benutzung eines Teams. Hier wird klar, wie ein Konnektor mit der Kollaboration zusammenhängt, die er einbinden soll: er verfeinert sie. (siehe „FlightBonus extends Bonus“) Anpassung: das A und O bei Wiederverwendung. Nun endlich auch auf Paketebene, denn Teams korrespondieren mit Paketen (Überleitung nächste Folie)

Was Teams noch leisten Vereinigung Paket & Klasse Kapselung Dateistruktur + Objektstruktur Eigene Attribute und Methoden Vererbung Kapselung Rollen können effektiv vor Zugriff geschützt werden Team ist Fassade Techniken der Alias Control: Typsystem berücksichtigt Instanzen Durch Betrachtung der Dateistruktur: Übergang vom Programming in the small, to programming in the large & in the many. Kapselung: teams sind Module, Komponente, Klassen, ...

Object Teams im Kontext Implementierung Compiler 1. Version: erprobt in Diplomarbeiten und einer Lehrveranstaltung 2. Version: Erweiterung des Java Compilers von Eclipse Laufzeitumgebung Load-time weaving: Späte Aspekt-Bindung Entwicklungsumgebung Eclipse-Erweiterung: Editieren Compilieren Navigieren ... Langsam aus den Details herauszoomen... Gründe für 2. Version Compiler: (Konsolidierung) bessere Integration in die IDE. Bei Bedarf erklären: Vorteile des Load-time weaving: Basis muss nicht explizit präpariert werden, d.h. keine Varianten der Basis (mit/ohne Aspekte) nötig Aspekte können noch beim Programmstart dazugebunden werden

Object Teams im Kontext (2) Praxiseinführung Verbundprojekt TOPPrax (TUB, TUD, FIRST, GEBIT, Daedalos) Evaluierung in vergleichenden Fallstudien Konsolidierung von Konzepten und Werkzeugen Umfassende Entwicklungsmethode Bewertung: Hilft AOP mit Object Teams für Qualität Verständlichkeit Wartung und Evolution ?