Werkzeugunterstützte Softwareadaption mit Inject/J Volker Kuttruff Thomas Genßler

Übersicht Einführung Softwareadaption mit Inject/J Anforderungen Überblick Inject/J Konzepte Korrektheit Beispiele Zusammenfassung und Ausblick Einführung Wieso Adaption von Software Probleme bei der Adaption von Software Softwareadaption Anforderungen an ein Adaptionswerkzeug

Änderung der Anforderungen erfordert Adaption Einführung Kontext Anforderungen an ein System ändern sich in den verschiedenen Entwicklungsstufen System Flexibilität Performance Struktur Persistenz und Datenmodell Kompositions- und Protokollanforderungen Wieso Adaption Softwareentwicklung ist evolutionärer Prozeß Anforderungen ändern sich - aufgrund äußerer Vorgaben - falsch verstanden - neu Flexibilität - System kann nicht / sehr schwer erweitert werden -> Restrukturierung Strukturelle und Schnittstellenanforderungen - Schnittstellen passen nicht zusammen - z.B. Versionswechsel JDK, andere Bibliothek Performance - Flexibilität oftmals nur in Entwicklungsphase gefordert, zur Laufzeit überflüssig/performancemindernd - z.B. überflüssige Indirektionen Kompositions- und Protokollanforderungen - Änderung der Interaktion/Kommunikation/Synchronisation bei Wiederverwendung Persistenz und Datenmodell - Änderung des Ablageformats - Änderung des Datenmodells (relational,objektorientiert) Änderung der Anforderungen erfordert Adaption

Einführung Adaptionsprobleme Adaptionen oftmals querschneidend Implementierung der Anforderungen im System verteilt Konsistente Adaptionen aufwendig Oftmals interne Implementierungsstrukturen betroffen Manuelle Adaption erfordert Verständnis des Quellcodes Adaptionen querschneidend - Anforderungen folgen nicht den Strukturierungsmöglichkeiten der Programmiersprache - Problem versucht AOP durch getrennte Spezifikation der Anforderungen zu lösen Implementierung verteilt - Adaption aufwendig, da u.U. sehr viele Codestellen betroffen (Benutzungsstellen) - Manuell zeitaufwendig und fehleranfällig - Blackbox-Adaption oftmals nicht ausreichend Manuelle Adaption - erfordert Verständnis des zu adaptierenden Codes - u.U. unerwünscht / unmöglich bei großen Systemen Werkzeugunterstützte Softwareadaption

Softwareadaption mit Inject/J Anforderungen Invasive Softwareadaption (Greybox-Adaption) Einfache Spezifizierung häufiger Trans-formationen auf geeignetem Abstraktionsniveau Verarbeitung bereits vorhandenen Quellcodes, insbesondere kein Paradigmenwechsel Wiederverwendbarkeit der Adaptionen Korrektheitsbegriff Anforderungen sind Erfahrungen aus internen Projekten und EU-Projekt TROOP Entscheidung für Greybox-Adaption: - Blackbox (Änderung der funktionalen Schnittstellen) in vielen Fällen nicht ausreichend - Whitebox meist zu aufwendig - große Metaprogramming-Blibiotheken erfordern lange Einarbeitungszeit - Adaptionsprogramme komplex und zeitaufwendig Einfache Spezifizierung - kurze Einarbeitungszeit - Viele Adaptionen sind ad-hoc Adaptionen - hohes Abstraktionsniveau, da sonst Spezifikation der Adaption komplexer als manuelle Ausführung Spezifikation der Adaptionen sollte relevanten Teil aller notwendigen Adaptionen abdecken. Vorhandener Quellcode - Adaptionen sollten auf vorhandenen Quellcode / alten Systemen funktionieren  (Reengineering-Gedanke) - kein Paradigmenwechsel, da Benutzer skeptisch gegenüber neuen Ansätzen - hohe Codequalität nach der Adaption Wiederverwendbarkeit - komplexere Adaptionen enthalten umfangreiches Know-How Korrektheitsbegriff - Adaptionen müssen definierten Korrektheitsbegriff unterliegen - Rücksetzbarkeit von Codeveränderungen

Überblick Inject/J Werkzeug für automatisierte Codetransformation Einfaches Metamodell Einfache Skriptsprache inkl. Skriptprozessor Arbeitet direkt auf Java-Quellcode Einsatzmöglichkeiten Ad-hoc Transformationen Querschneidende Adaptionen Entwurfsmusteroperatoren Gluecodegenerierung (Konnektoren) Allgemeine Codegenerierung Einfaches Metamodell / Skriptsprache -> kurze Einarbeitungszeit Benutzt Metaprogramming-Bibliothek für die eigentlichen Transformationen

Zentrale Konzepte Namensraum Webepunkte Navigation Transformation Enthält alle für die Adaption benötigten Java-Klassen Webepunkte Bilden Metamodell von Inject/J Navigation Auffinden der gesuchten Webepunkte Namensraum - u.U. nur Teilmenge des gesamten Systems - wird von außen übergeben Transformation sog. Webeoperationen ändern den Quelltext invasiv

Webepunkte Mögliche Transformationsstellen im System Identifizierung durch Name bzw. Signatur Implizite Webepunkte Klasse Methode Attribut Methoden-/Attributzugriff Zuweisungen Explizite Webepunkte Explizite Markierung potentieller Adaptionsstellen Mögliche Transformationsstellen - nicht alle denkbar möglichen Stellen sind transformierbar  Greybox-Charakter Identifizierung - nicht notwendigerweise einzelnes Element, kann auch eine Menge von Elementen sein Implizite Webepunkte durch das Sprachmetamodell gegeben

Navigation Hierarchische Navigation Direkte Navigation Spezifikation der Navigationsziele mit Hilfe regulärer Ausdrücke und Quantoren Beispiele: in class ´fzi.injectj.Main´ do ... foreach method ´put(java.lang.Object,*) do ... Auffinden der gesuchten Webepunkte im System Hierarchische Navigation entlang der Hierarchie des Sprachmetamodells - Notwendig, damit Webepunktnamen eindeutig Direkte Navigation - Erneutes Besuchen bereits durch hierarchische Navigation gefundener Webepunkte - Ermöglicht durch Referenzen auf diese WP

Webeoperationen before / after add change modifier replace delete Einfügen von Code vor bzw. nach dem Webepunkt add Einfügen von Code in listenartige Strukturen change modifier Ändert die Modifizierer eines Webepunktes replace Ersetzt den momentanen Quelltext durch ein neues Codefragment delete Before/after: - Bsp. Methode: before – Methodeneintritt after – alle regulären Methodenaustritte Add: - add to members: Methoden/Attribute in Klasse einfügen - add to implements Delete: - Prüfung, ob statische Referenzen existieren  Korrektheitsbegriff

Korrektheit Ist das System vor der Operation übersetzbar, so ist es auch nach der Operation übersetzbar. Sichergestellt durch umfangreiche Überprüfungen Prüfung auf Existenz von statischen Referenzen auf zu löschende Elemente Prüfung von Namenskonflikten Inkrementeller Parser Zusätzlich: Skriptbasierte Überprüfungen durch Webepunkt-Attribute Webepunkt-Attribute: - Namen - Klasse: Test ob Oberklasse einer anderen Klasse - Zugriff: Lese-/Schreib-/SchreibLeseZugriff - und vieles mehr

Beispiel (I) foreach class ´*´ do { foreach method ´*´ do { foreach access ´pop()´ <=a> to subclass ´java.util.Stack´ do { before ${ if (<a.prefixText>.empty()) System.err.println(„Empty stack...“); }$ } } } Beispiel: Einfügen von Debug-Code vor jedem Zugriff auf einen Stack. Es soll geprüft werden, ob Stack vor dem Zugriff leer ist

Beispiel (II) if (staticStack.empty()) System.out.println(„Empty stack...“); privateStack.push(staticStack.pop()); if (privateStack.empty()) System.out.println(„Empty stack...“); Object top = privateStack.pop(); this.pop();

Weitere Beispiele Observifier Beanifier Transformiert direkte Methodenaufrufe in nachrichtenbasierte Notifikation (Observer / Observable) ca. 170 Zeilen Skriptcode inkl. graphischer Benutzerinteraktion Beanifier Ersetzt Attributzugriffe durch Get/Set-Methoden Automatische Visitorgenerierung Observifier: - Entwurfsmusteroperator: nachträgliches Einfügen von Entwurfsmustern in bereits bestehende Systeme - Bei expliziter Programmierung >50KB Beanifier: - Beispiel zum forcieren von Coding-Guidelines Visitorgenerierung: - Codegenerierung / Assistent - Generierung der accep()-Methoden

Zusammenfassung Problem: Neues Werkzeug: Inject/J Aufwendige Adaptionen in großen Systemen aufgrund sich ändernder Anforderungen Neues Werkzeug: Inject/J Invasiv, nicht auf Blackbox-Adaption beschränkt Einfache Skriptsprache Kein Paradigmenwechsel, arbeitet mit vorhandenem Quelltext

Ausblick Unterstützung weiterer Webepunkte Verfeinerung des Transaktionsbegriffs Sprachmittel zur Spezifikation von Vorbedingungen Umgang mit unvollständigem Code Bibliotheken mit vorgefertigten Operationen Bessere Integration in Entwicklungsumgebungen Weitere Webepunkte: - Exception Handling Transaktion: - bisher: Ein komplettes Skript ist eine Transaktion - Teiltransaktionen innerhalb eines Skripts inkl. Zurücksetzen - Momentan Abbruch bei Fehler Spezifikation von Vorbedingungen - schon möglich mittels if/then-Konstrukten und Webepunkt-Attributen - gewünscht: effizientere Darstellung der Vorbedingungen Umgang mit unvollständigem Code - erfordert Überdenken des Korrektheitbegriffs Bibiotheken: - Stichwort Refactorings Integration: - Assistent existiert schon - Integration in JBuilder begonnen

Inject/J Webseite http://injectj.fzi.de Kontakte Thomas Genßler (genssler@fzi.de) Volker Kuttruff (kuttruff@fzi.de)