Software Evolution mit Legacy Systemen Forum Forschungsförderung / ViSEK Trends im Software Engineering Software Evolution mit Legacy Systemen Behutsame Modernisierung Jan Wloka <Jan.Wloka@first.fraunhofer.de>
Bekannte Situationen und Ursachen Situationen mit alter Software Ein System läuft stabil aber auf veralteter Hardware Wartung des Systems ist kostspielig Integrationsbemühungen werden massiv behindert Erweiterung der Funktionalität ist schwierig, wenn nicht sogar unmöglich Häufige Ursachen Starke Abweichungen zwischen Implementierung und Dokumentation "Featurerismus" Personal Fluktuation Seite 3 Das Problem Legacy Information System Definition Legacy System:... any information system that significantly resists modification and evolution... [Brodie, Stonebraker, 1995] Das Problem im Detail: Einzige Dokumentationsquelle ist der Quellcode Quellcode-Strukturen sind häufig spröde (brittle), Unflexibel, nicht erweiterbar Mangel an Offenheit für neue Funktionalitäten Isolierte Funktionalität Seite 4
Drei Kategorien von LösungsmL sungsmöglichkeitenglichkeiten Re-Development Neu-Entwicklung from scratch Neue Technologien, Architektur, Werkzeuge, etc. ABER: Sehr aufwendig, Keine Weiterverwendung, Ohne Erfolgsgarantie Wrapping Kapseln des Systems oder einzelner Systemteile Neue Schnittstellen zur Funktionalität Domäne der Komponenten-basierten Ansätze ABER: Keine Fehlerbehebung, Keine Verbesserung von System-Eigenschaften, Kaum erweiterbar Doch warum ist Wrapping häufig schwierig??????? Seite 5 Komplexe Strukturen und crosscutting crosscutting Funktionalitäten Besondere Probleme Komplexe Strukturen Beispiele: Starke Abhängigkeiten durch Vererbungs-/Benutzungsbeziehungen, Sehr lange Methoden Kaum verständlich da zu komplex crosscutting Funktionalitäten Liegen quer zur Struktur Schwer kappselbar Beispiele: Verteilung, Synchronisation, Notification, Logging, Exception-Handling, Memory-Management ClassA ClassB ClassC X X X Funktionalität 1 Funktionalität 2 X X X Funktionalität 3 Seite 6
crosscutting Funktionalitäten Ein Beispiel Werkzeug: Aspect Browser Identifikation von einzelnen Funktionalitäten mit Textanalyse (Regular Expressions) Beispiel: XML Parser Log ROT Write GRÜN Parse BLAU Seite 7 Re-Development Wrapping Re-Engineering Re-Engineering Analysieren/Verstehen und Abändern der existieren Quellen: Quellcode Analyse Zugang zur Funktionalität Modularisierung Separierung der Funktionalität Komposition Integration der Funktionalität Ziel: Die Implementierung in einer neuen Form wiederherzustellen??? Welche Möglichkeiten zur Modularisierung habe ich? Seite 8
Möglichkeiten zur Modularisierung Inkrementelle Strukturverbesserung Refactoring = methodisch fundierte Herangehensweise um strukturelle Änderungen in bestehenden Systemen gezielt und sicher durchzuführen Refactoring als Technik und vor allem methodischer Ansatz Bekannte, erprobte und Werkzeug-gestützte Technologie Strukturen werden zerlegt, entkoppelt und vereinfacht Verständnis und Modularität des bestehenden Systems werden verbessert Refactoring von OO-Strukturen Seite 9 Möglichkeiten zur Modularisierung Beschränkungen von Refactoring Quer zur Struktur liegende Funktionalität wird nur hin und her verschoben Komplexität wird nur lokal beseitigt (Wegräumen ohne Aufräumen) Designkonflikte können nicht immer aufgelöst werden z.b. Modularisierung nach Struktur (OO) vs. Modularisierung nach Funktion (Funktionale Psrogrammierung) OO Modularisierungsmöglichkeiten reichen nicht aus! Seite 10
Erweiterte Modularisierungskonzepte Aspektorientierte Softwareentwicklung Aspekte liegen quer zur Struktur Kapselung der crosscutting Funktionalitäten Aspektorientierte Programmierung: Kernsystem (OO) Aspekte beziehen sich auf das Kernsystem Aspekte müssen Quellen nicht verändern Integration durch Weaver ClassA m1() m2(p1) ClassB m2() m3(p1, p2) m4() ClassC m2() m5(p1) joinpoints Alle Methoden aus ClassA Alle Methoden m2 Alle parameterlosen Methoden Beispiele für Aspekte: Verteilung, Synchronisation, Logging, Exception-Handling, Memory-Management Techniken/Werkzeuge für unterschiedliche Sprachen verfügbar Kern Aspekte Seite 11 advice before after around Aspektorientierte Modularisierungstechniken Aspektorientierte Erweiterungen Für Java: AspectJ, Hyper/J, Object Teams Für C++: AspectC++, Object Teams AspectJ Erste Aspektorientierte Erweiterung Quellcode-Manipulation von außen Hyper/J Byte-Code Modifikation von außen Kein Quellcode nötig Object Teams Verbindung der Möglichkeiten verschiedener AO-Sprachen Seite 12
Lösungen und Probleme Separierung von quer zur Struktur liegender Funktionalität war unmöglich Aspekte ermöglichen deren Modularisierung und Komposition Aspekte für verschiedene Programmiersprachen verfügbar Offene Probleme: Methodisch richtige Separierung von Funktionalität in Aspekte Werkzeuge zum Auffinden und automatisierten Modularisierung Refactoring-Werkzeug für Aspekte FhI FIRST: Weiterentwicklung der Programmiersprache Object Teams Werkzeuge zur automatisierten Modularisierung in Aspekte Seite 13 Fazit Modernisierung ist Bestandteil fast jedes Softwareentwicklungsprojektes Für viele Probleme sind bereits Lösungen vorhanden Techniken der AOSD scheinen besonders geeignet, dabei Quellcode-Analyse technisch noch nicht ganz ausgereift, aber hilfreich Modularisierungstechniken ausreichend vorhanden, methodische Unterstützung? Kompositionsmöglichkeiten Teillösungen sind vorhanden, aber nicht vereint Was Fehlt: Integrierte Werkzeugunterstützung die Einzelwerkzeuge vereinigt Seite 14
Haben Sie Fragen? Jan Wloka <Jan.Wloka@first.fraunhofer.de> Seite 15