Software Factories SS Prof. Dr. Dirk Müller. 9 Aspektorientierte Programmierung

Transkript

1 Software Factories 9 Aspektorientierte Programmierung Prof. Dr. Dirk Müller

2 Übersicht Motivation Scattering und Tangling Separation of Concerns Geschichte und Terminologie Fallstudie: Patientendatensystem Join Point Models AspectJ-Beispiel: Tracing Probleme der aspektorientierten Programmierung Zusammenfassung 2/27

3 Motivation Design for Change, Wiederverwendbarkeit von Software Separation of Concerns als Grundprinzip guten Designs jede Komponente (Klasse, Methode, Prozedur, etc.) macht eine und nur eine Sache aber: in Praxis manchmal N-zu-M-Beziehung zwischen Anforderungen und Komponenten 1 Anforderung in mehreren Komponenten umgesetzt in 1 Komponente mehrere Anforderungen implementiert Systemdekomposition in konventionellen höheren Sprachen lässt nur 1 Dimension zu, aber mehrdimensionales Problem Lösungsansatz: Aspekte kapseln Funktionalität für Crosscutting Concerns (querschnittliche Belange) und werden dann an wohldefinierten Stellen ins Programm gewoben 3/27

4 Concern dt. in etwa Belang Definition ist nicht einfach und variiert stark ein Element der Funktionalität eines Systems irgendeine Sache, die an einem System interessiert Reduktion auf den Bezugspunkt System/Programm nicht angemessen, da auch Herkunft der Belange wichtig reflektieren die Anforderungen an ein System, welche Beteiligte und Auftraggeber stellen und priorisieren Def.: etwas, das von Interesse oder Bedeutung für einen Beteiligten oder eine Gruppe von Beteiligten ist [2], S. 4 spezifische Anforderung oder Gesichtspunkt, welche(r) in einem Software-System behandelt werden muss, um übergreifende Systemziele zu erreichen Quelle: [2] zu speziell zu allgemein 4/27

5 Typen von Concerns funktionale Belange z. B. Zugkontrollsystem mit dem Bremsen eines Zuges Quality-of-Service-Belange (Dienstgüte) beschreiben nicht-funktionales Verhalten z. B. Leistung (via Caches), Zuverlässigkeit, Verfügbarkeit Policy-Belange als allgemeine Richtlinien zur Benutzung des Systems incl. Safety, Security und Geschäftsregeln System-Belange, die das System als ganzes betreffen z. B. Änderbarkeit und Konfigurierbarkeit organisatorische Belange Einhaltung des Budgets und des Termins Wiederverwendung von Software manchmal nicht als Concern angesehen, da Bezug auf Entwicklungsprozess Erhaltung oder Verbesserung der Reputation der Organisation Quelle: [2], S. 4 5/27

6 Cross-cutting Concerns (CCCs) Def.: Anforderung an ein Softwareprodukt, die modulübergreifend einzuhalten oder umzusetzen ist typischerweise Zusatz- oder Metaanforderungen, Gegensatz Kernfunktionalitäten (engl. Core Concerns) z. B. Fehlerbehandlung, Logging, Tracing und Sicherheitsanforderungen dt. in etwa quer schneidende Kernfunktionalität Lösungsansätze generative Programmierung Verwendung spezieller Frameworks Verwendung von Mustern wie Mix-in-Klassen aspektorientierte Programmierung 6/27

7 Beispiel: CCCs beim Online-Banking Anforderungen zur Aufnahme eines neuen Kunden Anforderungen zur Arbeit des Kunden mit einem Konto Anforderungen zum Kundenmanagement 3 Core Concerns Security- Anforderungen Recovery- Anforderungen 2 Cross-cutting Concerns Quelle: [2], S. 5 7/27

8 Scattering und Tangling von Code Scattering (1-zu-N-Beziehung) dt. in etwa verstreuen eine Anforderung mit Auswirkungen auf mehrere Module redundante oder sehr ähnliche Codeblöcke => schwer zu warten hohe Fehleranfälligkeit bei Änderungen Tangling (N-zu-1-Beziehung) dt. in etwa vermischen Code in einem Modul implementiert verschiedene Anforderungen schlechte Lesbarkeit und Rückverfolgbarkeit schlecht wiederverwendbar treten meist in Kombination auf beide als Bad Smells bzgl. des großen Ziels der Softwaretechnik Design for Change anzusehen 8/27

9 Beispiel für Tangling synchronized void put (SensorRecord rec ) { // Check that there is space in the buffer; wait if not if ( numberofentries == bufsize) wait () ; // Add record at end of buffer store [back] = new SensorRecord (rec.sensorid, rec.sensorval) ; back = back + 1 ; // If at end of buffer, next entry is at the beginning if (back == bufsize) back = 0 ; numberofentries = numberofentries + 1 ; // indicate that buffer is available notify () ; } // put Vermischung von Puffermanagement- und Synchronisations-Code Quelle: [2], S. 6 9/27

10 Beispiel für Scattering verstreuter Belang der Statistik im Patientendatensystem Probleme manifest bei Änderung Herausfiltern der Teile, die zu ändern sind viele Änderungen und viele Tests erhöhte Chance, neue Fehler einzuführen Quelle: [2], S. 6 f. 10/27

11 Geschichte Vorläufer: Reflexion und Metaobjekt-Protokolle, subjektorientierte Programmierung, Kompositionsfilter und adaptive Programmierung Team von Gregor Kiczales bei Xerox PARC 1997 Theorie 2001 AspectJ, heute verbreitetste aspektorientierte Sprache/Spracherweiterung Microsoft Transaction Server (1996) und Enterprise Java Beans (EJB, 1998) als erste Frameworks, die AOP anwenden 11/27

12 Einordnung des Programmierparadigmas nicht-strukturierte Programmierung ( Spaghetti-Code ) strukturierte Programmierung blockbasierte Programmierung modulare Programmierung objektorientierte Programmierung klassenbasiert prototypenbasiert Separation of Concerns rollenorientiert subjektorientiert aspektorientierte Programmierung manchmal nicht mehr als strukturierte Programmierung angesehen, da der Kontrollfluss immer wieder unterbrochen wird [2], S. 21 Bei Abstraktion zu weit gegangen? Kapselung von Funktionalität konsequent weitergeführt Wartbarkeit und Wiederverwendbarkeit nochmals verbessert 12/27

13 Terminologie Aspekt Programmabstraktion, die einen Cross-cutting Concern definiert, enthält Advice und Pointcut Advice Code, der einen Concern implementiert (Was?) Pointcut Spezifizierung der Stellen, an denen der Advice ausgeführt werden soll, durch Join Points (Wo?) Join Point Ereignis in einem Programm zur Laufzeit als Trigger für die Ausführung eines Advice Join Point Menge von Ereignissen, die in einem Pointcut Model angesprochen werden können; spezifisch für AOP-Programmiersprache Einweben Einfügen von Advice-Code an den angegebenen Join Points durch einen Aspekt-Weber Quelle: [2], S. 7 13/27

14 Fallstudie: Patientendatensystem persönliche Daten + Medikation können geändert werden updatepersonalinformation (patientid, infoupdate) updatemedication (patientid, medicationupdate) Sicherheitsproblem festgestellt Patientendaten sind bösartig manipuliert worden mögliche Ursachen: aus Bequemlichkeit eingeloggt geblieben und eine rauchen gegangen, dann Manipulation durch Unbefugten oder Manipulation durch Insider (Mitarbeiter) zwei Varianten einer neuen Sicherheitsvorschrift update-methoden in jeder Komponente ändern, so dass dort Authentifizierung und Logging aufgerufen wird vor update-methodenaufruf jeweils Authentifizierung und danach jeweils Logging aufrufen Quelle: [2], S. 8 f. Tangling Scattering 14/27

15 Authentifizierungs-Aspekt aspect authentication Führe vor allen Methoden, deren Name mit { update beginnt, den folgenden Advice aus! before: call (public void update* (..)) // this is a pointcut { // this is the advice that should be executed when woven into // the executing system int tries = 0 ; string userpassword = Password.Get ( tries ) ; while (tries < 3 && userpassword!= thisuser.password ( ) ) { // allow 3 tries to get the password right tries = tries + 1 ; userpassword = Password.Get ( tries ) ; } if (userpassword!= thisuser.password ( )) then //if password wrong, assume user has forgotten to logout System.Logout (thisuser.uid) ; } } // authentication Authentifizierung und Logging sind CCCs und sollten als Aspekte implementiert werden Alleinstellungsmerkmal: Aspekt benötigt Angabe, wo er ausgeführt werden soll (via Pointcut) Quelle: [2], S. 9 15/27

16 Join Point Models Aufruf-Ereignisse (Methode oder Konstruktor) Ausführungs-Ereignisse (Methode oder Konstruktor) Initialisierungs-Ereignisse (Klasse oder Objekt) Daten-Ereignisse (Zugriff auf ein Feld oder Aktualisierung eines Feldes) Ausnahme-Ereignisse (Behandlung einer Exception) Quelle: [2], S /27

17 Möglichkeiten des Einwebens vor einer speziellen Methode, einer Liste von Methoden oder einer per Schablonenmuster ausgewählten Untermenge von Methoden z. B. update* nach normaler oder Ausnahme-Rückkehr von einer Methode z. B. nach allen Aufrufen von update-methoden Logging durchführen als Ersatz für eine Methode bzw. mehrere Methoden eine Art Umleitung des Kontrollflusses bei Änderung eines Feldes in einem Objekt z. B. Überwachung oder angepasste Änderung auf standardisierte Werte Quelle: [2], S /27

18 Beispiel: Einweben zweier Aspekte Authentifizierungs- Aspekt Patient Logging- Aspekt Patient... updatedetails(...)... Aspekt- Weber... Authentifizierungs-Code updatedetails(...) Logging-Code... Quelle: [2], S /27

19 Arten des Einwebens in den Quellcode mittels eines Präprozessors bei AspectX angewandt beim Linken mittels eines modifizierten Compilers bei AspectJ angewandt: AspectJ-Compiler ajc, kann über Projekt AJDT in Eclipse integriert werden goldener Mittelweg dynamisches Einweben zur Laufzeit Überwachung (Monitoring) von Join Points Abgleich mit Pointcuts, bei Übereinstimmung Ausführung des entsprechenden Advice Flexibilität Laufzeit-Overhead Quelle: [2], S. 10 f. 19/27

20 AspectJ-Beispiel: Tracing (1/4) 20/27

21 AspectJ-Beispiel: Tracing (2/4) 21/27

22 AspectJ-Beispiel: Tracing (3/4) alle Methoden, deren Name mit my beginnt Rückgabetyp muss passen 22/27

23 AspectJ-Beispiel: Tracing (4/4) zusätzlich: Kontext muss vom Typ AOPDemo sein zweimal im statischen Kontext => Pointcut passt jeweils nicht mehr 23/27

24 Problem: Pointcut-Spezifikation völlig neu, also ungewohnt, und entscheidend große Sorgfalt nötig Fehler hier führt zum Einweben an falschen Stellen unerwartetes oder unvorhersehbares Programmverhalten Namenskonventionen überall streng einhalten jetzt Verarbeitung durch Werkzeug, nicht mehr nur für bessere Lesbarkeit durch Menschen Aspekt-Interferenz mehrere Aspekte wirken am selben Join Point am besten ganz umgehen schwer zu analysieren vollständige Unabhängigkeit voneinander sicherstellen, auch von Reihenfolge (keine Kontrolle, wie der Aspekt-Weber einwebt) Quelle: [2], S /27

25 Probleme: Inspektion und Testen bei AOP erschwerte Nachvollziehbarkeit von AOP-Programmen Inspektion: sequenzielles Lesen von Code nicht mehr auf einfache Art möglich Inspektion wird sehr schwierig aber: manchmal Werkzeuge zum AOP-Code-Lesen verfügbar Serialisierung ( Flachklopfen ) des Codes funktioniert nicht mehr beim dynamischen Einweben Konfliktauflösung (Priorisierung) des Aspekt-Webers muss auch diesem Werkzeug bekannt sein Testen: besonders problematisch bei Whitebox-Tests Entwurf von Defekttests unter Nutzung der Implementierung (mögliche Schwachstellen finden) erschwert, da nicht mehr linear Abdeckung (Coverage): Jeder Aspekt mit jedem Join Point? unerwartete Wechselwirkungen möglich enge Kopplung an den Basis-Code macht isolierten Test schwer Quelle: [2], S. 21 f. 25/27

26 Zusammenfassung Separation of Concerns konsequent umgesetzt, somit bessere Wiederverwendung und Änderbarkeit Beziehung Anforderung-Komponente 1:N beim Scattering, N:1 beim Tangling AOP erlaubt auch für Cross-cutting Concerns 1:1-Beziehungen Aspekte enthalten einen Pointcut (Wo eingewoben?) und einen Advice (Was eingewoben?) Join Points als Ereignisse, die in einem Pointcut abhängig vom Join Point Model angegeben werden können große Sorgfalt bei Pointcuts und Namenskonventionen nötig statische und dynamische Qualitätskontrolle erschwert erschwerte Nachvollziehbarkeit als Preis für höhere Abstraktion isoliertes Testen kaum möglich, da Wechselwirkungen Barriere für Anwendung in großen Software-Projekten verbesserte Werkzeuge zur Abmilderung der Probleme 26/27

27 Literatur [1] Hartmut Fritzsche, Software Factories Skript zur Lehrveranstaltung, , Download am , [2] Ian Sommerville: 31 Aspect-oriented software engineering, Online-Kapitel zum Buch Software Engineering 10, 2013/14, Download am , [3] AspectJ Frequently Asked Questions, Download am , 27/27