Migrationsstrategien. Dr. Thorsten Arendt Marburg, 22. Januar 2015

Transkript

1 Migrationsstrategien Dr. Thorsten Arendt Marburg, 22. Januar 2015

2 Re-Engineering Patterns [Demeyer et al.] 2 Software-Evolution WS 2014/2015

3 Überblick Probleme Wenn man ein bestehendes System re-engineered Wird das neue System von den Nutzern akzeptiert? Wie migriert man, während das Altsystem weiter benutzt wird? Wie kann das neue System evaluiert werden? Gewinne das Vertrauen der Nutzer und arbeite eng mit Ihnen zusammen Erarbeite eine Strategie für die schrittweise, inkrementelle Migration zum neuen System 3 Software-Evolution WS 2014/2015

4 Einbindung der Nutzer Probleme: Wird das neue System von den Nutzern akzeptiert? Das Altsystem tut doch, was es soll. Warum den Umgang mit einem System lernen, das das gleiche tut? Wie kann man Nutzer in die Softwareentwicklung einbinden, wenn das System noch nicht fertig gestellt ist? Lösung: Probleme Direkte Einbindung der Nutzer in die Entwicklung Enge Unterstützung in der Benutzung 4 Software-Evolution WS 2014/2015

5 Vor- und Nachteile dieser Technik (Enge Einbindung der Nutzer) Vorteile Nachteile Anforderungen werden laufend überprüft Sich nützlich fühlende Nutzer geben brauchbares Feedback Kostenersparnis hinsichtlich detailliertem Training nach Einführung des Systems Ablenkung von der eigentlichen Re-Engineering- Aufgabe Weckt zusätzliche Erwartungen Druck auf Entwickler wächst Nicht jeder Nutzer kann eingebunden werden unberücksichtigte Nutzer könnten verärgert werden 5 Software-Evolution WS 2014/2015

6 Aufbau von Vertrauen Probleme: Re-Engineering-Projekten werden oft Vorbehalte und Zweifel entgegen gebracht. Warum? Nutzer (und Entwickler) sind schwer von der Notwendigkeit zum Re-Engineering zu überzeugen Lösung: Probleme Erschaffe eine positive Atmosphäre Präsentiere erste Ergebnisse so früh wie möglich Präsentiere neue Ergebnisse in regelmäßigen, kurzen Intervallen 6 Software-Evolution WS 2014/2015

7 Vor- und Nachteile dieser Technik (Vertrauen durch inkrementelle Präsentation) Vorteile Nachteile Nutzer und Entwickler können den tatsächlichen Fortschritt nachvollziehen Kosten für kleinere Inkremente können besser abgeschätzt werden Zeitaufwändig Zu früh präsentierte gute Lösungen erwecken zusätzliche Erwartungen Druck auf Entwickler wächst Nicht alle Anforderungen können in Inkremente herunter gebrochen werden 7 Software-Evolution WS 2014/2015

8 Inkrementelle Migration Probleme: Tatsächliche Anforderungen werden oft erst später klar Unzufriedene Nutzer bei grundlegend anderer Benutzung der neuen Software als zuvor Auslieferung unfertiger und/oder fehlerhafter Software Späte Auslieferung spätes Feedback Wann soll das neue System ausgeliefert werden? Lösung: Probleme Eine erste Version so schnell wie möglich Anschließend inkrementelle Migration 8 Software-Evolution WS 2014/2015

9 Schritte bei inkrementeller Migration Zerlegung des Altsystems in Komponenten Bearbeitung jeweils einer Komponente Testerstellung Feedback Re- Engineering Ausliefern Testen 9 Software-Evolution WS 2014/2015

10 Vor- und Nachteile dieser Technik (Inkrementelle Migration) Vorteile Nachteile Frühes Feedback Nutzer lernen das neue System bereits zur Entwicklungszeit kennen Das System ist immer in einem getesteten und ausgelieferten Zustand Es ist schwierig, das System ständig am Laufen zu halten Es ist riskant, ein laufendes System ständig zu ändern Anwendung der Technik bei Architekturänderung unter Umständen nicht oder nur bedingt möglich 10 Software-Evolution WS 2014/2015

11 Prototyping Probleme: Es ist riskant, ein laufendes System radikal zu ändern Es ist schwer, die Auswirkungen des neuen Systems auf die existierende Funktionalität abzuschätzen Wie stellt man sicher, dass das neue System funktioniert und auch angenommen wird? Lösung: Probleme Erstellung eines Prototyps des neuen Konzepts Evaluation des Prototyps hinsichtlich neu entstehender Anforderungen 11 Software-Evolution WS 2014/2015

12 Arten von Prototypen Prototyp exploratorisch evolutionär Prototyp wird anschließend weggeworfen Konkrete (technische) Aspekte, die durch den Prototyp betrachtet werden sollen, z.b. Prototyp wird (eventuell) zum Zielsystem weiterentwickelt das Altsystem ersetzen Performance Usability 12 Software-Evolution WS 2014/2015

13 Vor- und Nachteile dieser Technik (Prototyping) Vorteile Schnelle Erstellung Teile des Altsystems können unter Umständen zum Prototypen beitragen Schnelles Feedback, ob das neue Konzept stimmig ist oder nicht Nachteile Warum sollten die Nutzer einen Wegwerf-Prototypen benutzen und bewerten? Man wird verleitet, den Wegwerf-Prototypen weiter zu entwickeln Es kann aufwändig sein, einen evolutionären Prototypen immer auf dem neuesten Stand zu halten 13 Software-Evolution WS 2014/2015

14 Nachhaltigkeit Probleme: Wie überzeugt man die Nutzer, dass das Re-Engineering stetig vorankommt? Wie stellt man sicher, dass aktuelle Änderungen die bisherige Funktionalität nicht beeinflussen? Lösung: Regelmäßige (tägliche?) Integration aktueller Änderungen und Entwicklungen (Continuous Integration) Werkzeuge: CI-Server, z.b. Hudson, Bamboo Durchführen von Regressionstests Probleme 14 Software-Evolution WS 2014/2015

15 Vor- und Nachteile dieser Techniken (Continuous Integration und Regressionstests) Vorteile Es ist immer eine laufende, aktuelle Version der neuen Software vorhanden Nachteile Änderungen müssen kontinuierlich integriert werden (Disziplin) Änderungen werden schnell evaluiert 15 Software-Evolution WS 2014/2015

16 Datenmigration Probleme: Während der inkrementellen Migration zum neuen System müssen Daten, die auch von Teilen des Altsystems verwendet werden, weiterhin verfügbar bleiben Wie können Daten, die sowohl vom Altsystem als auch vom neuen System verarbeitet werden, migriert werden? Lösung: Probleme Entwicklung einer Datenbrücke zum inkrementellen Überführen der Daten vom Altsystem zum neuen System 16 Software-Evolution WS 2014/2015

17 Datenbrücke [Demeyer et al.] Die Brücke ist verantwortlich für das Propagieren von Lese-Anfragen vom neuen an das Altsystem das Konvertieren der Daten Propagieren von Schreib-Anfragen vom Altsystem an das neue System 17 Software-Evolution WS 2014/2015

18 Vor- und Nachteile dieser Technik (Datenmigration über Datenbrücke) Vorteile Das neue System kann in Betrieb genommen werden, ohne dass alle Daten migriert wurden Nachteile Die korrekte Implementierung der Brücke kann knifflig sein Migrierte Daten können nur schwer wieder zurück migriert werden Performance Overhead 18 Software-Evolution WS 2014/2015

19 Schnittstellen Probleme: Das neue System muss noch Funktionalität des alten Systems benutzen, jedoch sind die entsprechenden Schnittstellen nicht adäquat genug Wie kann während des Migrationsprozesses auf Services des Altsystems zugegriffen werden? Lösung: Probleme Bestimmen der adäquaten Abstraktionen Wrappen der Services des Altsystems, um diese Abstraktionen zu emulieren 19 Software-Evolution WS 2014/2015

20 Vor- und Nachteile dieser Technik (Emulieren adäquater Schnittstellen) Vorteile Je früher man die Schnittstellen des Altsystems nicht mehr benutzt, desto weniger beeinflusst die alte Architektur den Migrationsprozess Nachteile Instabile neue Schnittstellen können zu zögernder Nutzung derselben führen Vorsicht: Prozedurale Abstraktionen nicht als Utility-Klassen wrappen! 20 Software-Evolution WS 2014/2015

21 Öffentliche vs. veröffentlichte Schnittstellen Probleme: Schnittstellen des neuen Systems sind noch instabil Wie kann von Schnittstellen des Altsystems auf Schnittstellen des neuen Systems migriert werden, obwohl sich diese noch in Entwicklung befinden? Lösung: Probleme Unterscheide zwischen öffentlichen und veröffentlichten Schnittstellen Öffentlich: stehen dem Rest des Systems zur Verfügung Veröffentlicht: instabile Schnittstellen eines Subsystems 21 Software-Evolution WS 2014/2015

22 Vor- und Nachteile dieser Technik (Öffentliche vs. veröffentlichte Schnittstellen) Vorteile Transparente Stabilität Nutzer von veröffentlichten Schnittstellen können das Risiko ihrer Verwendung besser abschätzen Nachteile Technik benötigt Konventionen und Disziplin Warum eine instabile Schnittstelle nutzen? 22 Software-Evolution WS 2014/2015

23 Änderung von öffentlichen Schnittstellen Probleme: Öffentliche Schnittstellen können viele Nutzer haben Viele öffentliche Schnittstellen hohe Wartungskosten Wie kann eine öffentliche Schnittstelle geändert werden, ohne ihre Nutzer zu beschädigen? Lösung: Die Schnittstelle als veraltet (deprecated) markieren Andere Lösungen: Nutzer direkt informieren Probleme Warnungen (zur Laufzeit, Logging, zur Kompilierzeit, etc.) 23 Software-Evolution WS 2014/2015

24 Vor- und Nachteile dieser Technik (Änderung von öffentlichen Schnittstellen) Vorteile Nutzer müssen ihre Implementierungen nicht sofort ändern Zeitfenster zum Überdenken der Entscheidungen Nachteile Kann durch Nutzer ignoriert werden Wann die veraltete Schnittstelle löschen? 24 Software-Evolution WS 2014/2015

25 Weitere Migrationsstrategien Erhalte die Vertrautheit in das System Radikale Neuerungen können Nutzer verschrecken Vermeide radikale Neuerungen durch eine konstante und relativ kleine Anzahl an Änderungen zwischen den Releases Manchmal aber nicht möglich Optimiere Funktionalität nur, wenn tatsächlich angebracht Nur Bottlenecks sollten optimiert werden (Analyse!) Performance-Gewinn muss ersichtlich sein (Bechmarks) Do it, then do it right, then do it fast 25 Software-Evolution WS 2014/2015

26 Migrations-Patterns: Zusammenfassung [Demeyer et al.] 26 Software-Evolution WS 2014/2015

27 Quellen und Werkzeuge Literatur: Serge Demeyer, Stephane Ducasse, Oscar Nierstrasz: Object-Oriented Reengineering Patterns, 2013, Kap. 7, online verfügbar unter Werkzeuge: Hudson Integration Server: Atlassian Bamboo: 27 Software-Evolution WS 2014/2015