Software Factories, SS 2018 - htw-dresden.demuellerd/SWFac_SS2018/09_AspektProg.pdfSS 2018 Dirk Müller: Software Factories 4/27 Concern dt. in etwa Belang Definition ist nicht einfach

Software Factories

SS 2018

Prof. Dr. Dirk Müller

9 Aspektorientierte Programmierung

SS 2018Dirk Müller: Software Factories

2/27

Übersicht

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


3/27

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 Cross-cutting Concerns (querschnittliche Belange) und werden dann an wohldefinierten Stellen ins Programm gewoben


4/27

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


5/27

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– Erhaltung oder Verbesserung der Reputation der Organisation

Quelle: [2], S. 4

manchmal nichtals Concernangesehen,

da Bezug aufEntwicklungsprozess


6/27

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 Belange“● Lösungsansätze

– generative Programmierung– Verwendung spezieller Frameworks– Verwendung von Mustern wie Mix-in-Klassen– aspektorientierte Programmierung


7/27

Beispiel: CCCs beim Online-Banking

Quelle: [2], S. 5

Anforderungen zurAufnahme eines neuenKunden

Anforderungen zurArbeit des Kundenmit einem Konto

Anforderungen zumKundenmanagement

Security-Anforderungen

Recovery-Anforderungen

3 Core Concerns

2 Cross-cuttingConcerns


8/27

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


9/27

Beispiel für Tangling

Quelle: [2], S. 6

synchronized void put (SensorRecord rec ){

// Check that there is space in the buffer; wait if notif ( numberOfEntries == bufsize)

wait () ;// Add record at end of bufferstore [back] = new SensorRecord (rec.sensorId, rec.sensorVal) ;back = back + 1 ;// If at end of buffer, next entry is at the beginningif (back == bufsize)

back = 0 ;numberOfEntries = numberOfEntries + 1 ;// indicate that buffer is availablenotify () ;

} // put

Vermischung von Puffermanagement- und Synchronisations-Code


10/27

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.


11/27

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


12/27

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

● Kapselung von Funktionalität konsequent weitergeführt– Wartbarkeit und Wiederverwendbarkeit nochmals verbessert

manchmal nicht mehr alsstrukturierte Programmierung

angesehen, da der Kontrollflussimmer wieder unterbrochen wird

[2], S. 21Bei Abstraktion

zu weit gegangen?


13/27

Terminologie

● Aspekt Programmabstraktion, die einen Cross-cuttingConcern definiert, enthält Advice und Pointcut

– Advice Code, der einen Concern implementiert (Was?)– Pointcut Spezifizierung der Stellen, an denen der Advice aus-

geführt werden soll, durch Join Points (Wo?)

● Join Point Ereignis in einem Programm zur Laufzeit alsTrigger für die Ausführung eines Advice

● Join Point Menge von Ereignissen, die in einem PointcutModel angesprochen werden können; spezifisch für

AOP-Programmiersprache● Einweben Einfügen von Advice-Code an den

angegebenen Join Points durch einenAspekt-Weber

Quelle: [2], S. 7


14/27

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 Unbefugtenoder

– 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

Tangling

ScatteringQuelle: [2], S. 8 f.


15/27

Authentifizierungs-Aspekt

Quelle: [2], S. 9

aspect authentication{

before: call (public void update* (..)) // this is a pointcut{

// this is the advice that should be executed when woven into// the executing systemint tries = 0 ;string userPassword = Password.Get ( tries ) ;while (tries < 3 && userPassword != thisUser.password ( ) ){

// allow 3 tries to get the password righttries = tries + 1 ;userPassword = Password.Get ( tries ) ;

}if (userPassword != thisUser.password ( )) then//if password wrong, assume user has forgotten to logoutSystem.Logout (thisUser.uid) ;

}} // authentication

Führe vor allen Methoden, deren Name mitupdate beginnt, den folgenden Advice aus!

● Authentifizierung und Logging sind CCCs und sollten als Aspekte implementiert werden● Alleinstellungsmerkmal: Aspekt benötigt Angabe, wo er ausgeführt werden soll (via Pointcut)


16/27

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. 10


17/27

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. 10


18/27

Beispiel: Einweben zweier Aspekte

Authentifizierungs-Aspekt

Aspekt-Weber

Logging-Aspekt

Patient

...updateDetails(...)...

Patient

...Authentifizierungs-CodeupdateDetails(...)Logging-Code...

Quelle: [2], S. 11


19/27

Arten des Einwebens

● in den Quellcode mittels eines Präprozessors– bei AspectX angewandt

● beim Linken mittels eines modifiziertenCompilers– bei AspectJ angewandt: AspectJ-Compiler ajc,

kann über Projekt AJDT in Eclipse integriertwerden

● dynamisches Einweben zur Laufzeit– Überwachung (Monitoring) von Join Points– Abgleich mit Pointcuts, bei Übereinstimmung

Ausführung des entsprechenden Advice

Fle

xib

ilitä

t

Lau

fzei

t-O

verh

ead

goldener Mittelweg

Quelle: [2], S. 10 f.


20/27

AspectJ-Beispiel: Tracing (1/4)


21/27



22/27


Rückgabetyp musspassen

alle Methoden, deren Namemit my beginnt


23/27


zusätzlich: Kontext mussvom Typ AOPDemo sein

zweimal im statischenKontext => Pointcut passt

jeweils nicht mehr


24/27

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. 20


25/27

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.


26/27

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 – ab-hä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


27/27

Literatur

[1] Hartmut Fritzsche, „Software Factories – Skript zur Lehrveranstaltung“, 11.01.2016, Download am 6.4.2016,http://www2.htw-dresden.de/~fritzsch/SF/Software_Factories_Skript.pdf

[2] Ian Sommerville: „31 Aspect-oriented software engineering“, Online-Kapitel zum Buch „Software Engineering 10“, 2013/14, Download am 19.05.2016, http://iansommerville.com/software-engineering-book/files/2014/07/Ch-31-Aspect-oriented-SE.pdf

[3] „AspectJ Frequently Asked Questions“, Download am 19.05.2016, http://www.eclipse.org/aspectj/doc/released/faq.php

http://www2.htw-dresden.de/~fritzsch/SF/Software_Factories_Skript.pdf

http://iansommerville.com/software-engineering-book/files/2014/07/Ch-31-Aspect-oriented-SE.pdf

http://www.eclipse.org/aspectj/doc/released/faq.php

Documents

Software Factories, SS 2018 - htw-dresden.demuellerd/SWFac_SS2018/09_AspektProg.pdfSS 2018 Dirk Müller: Software Factories 4/27 Concern dt. in etwa Belang Definition ist nicht einfach