Software-Evolution: Zusammenfassung. Dr. Thorsten Arendt Marburg, 12. Februar 2015

Transkript

1 Software-Evolution: Zusammenfassung Dr. Thorsten Arendt Marburg, 12. Februar 2015

2 16. Oktober 2014: Einführung Was ist Software-Evolution? Wartung und Pflege von Softwaresystemen Erweiterung von Software bezüglich neuer Anforderungen Warum ist (systematische) Software-Evolution wichtig? Software-Entwicklung ist häufig langfristig angelegt Es gibt immer mehr Software Warum altert Software? Durch zu wenig Anpassungen, durch Anpassungen selbst oder durch unzureichende Aufräumarbeiten Woran erkennt man, dass Software altert? Fehlende Tests, Dokumentation und fehlendes Detail-Wissen, kontinuierliche Fehlersuche, lange Entwicklungszeiten, etc. Warum ein Software-System ändern? Neue Anforderungen, Verbesserungen, neue Umgebung 2 Software-Evolution WS 2014/2015

3 Die Gesetze von Lehman: Kurzbeschreibung und Bezug zu Open Source Software (OSS) Gesetz Kurzbeschreibung OSS Fortlaufende Änderungen Wachsende Komplexität Stabile Kenngrößen Organisatorische Stabilität Notwendige Vertrautheit Kontinuierliches Wachstum Abnehmende Qualität Feedback Nutzung in realer Umgebung führt zu Änderungen Nutzung und Änderung führt zu höherer Komplexität Software-Evolution folgt festen Regeln (invariante Kenngrößen) Stabile und (relativ) Kosten- bzw. Ressourcenunabhängige Entwicklung Langfristig konstanter inkrementeller Zuwachs Steigende Nachfrage führt zu mehr Funktionalität Ohne systematische Pflege nimmt Qualität ab Entwicklungsprozesse sind Feedback-Systeme 3 Software-Evolution WS 2014/2015

4 23. Oktober 2014: Evolutionsprozesse Einbettung von Evolution in Softwareentwicklungsprozesse Wasserfallmodell, V-Modell, Rational Unified Process, iterative Softwareentwicklung, agile Methoden, etc. Evolutionsprozesse Änderungsanforderungen sind die Auslöser für Software-Evolution. Wahl ist abhängig von der Art des Systems, des bisher verwendeten Entwicklungsprozesses und der Erfahrung / dem Wissen der Entwickler Jeder iterative Entwicklungsprozess kann für Software Evolution verwendet werden (z.b. Minizyklus, siehe nächste Folie) Dringende Änderungen dürfen realisiert werden, ohne alle Schritte eines wohldefinierten Evolutionsprozesses zu durchlaufen Evolutionskosten sind schwer abzuschätzen. Von der Software abhängige und unabhängige Kosten (interne und externe Faktoren) 4 Software-Evolution WS 2014/2015

5 Evolutionsprozesse: Minizyklus Änderungsanforderung Änderung der Anforderungsbeschreibung Planungsphase Verstehen betroffener Programmkomponenten Analyse der Änderungsauswirkungen Realisierung der Änderung Umstrukturierung/Refactoring, um die anstehende Änderung leichter durchführen zu können Alle betroffenen Teile ändern Evaluation des Softwaresystems Regressionstests Anpassung der Dokumentation 5 Software-Evolution WS 2014/2015

6 30. Oktober 2014: Qualitätssicherung von Softwaremodellen Qualitätsaspekte: Softwarequalität vs. (Software-) Modellqualität Softwarequalität: Norm/Standard ISO/IEC 9126 Modellqualität: nicht standardisiert (aber: 6C-Ziele) Ein generischer, strukturierter Qualitätssicherungsprozess für Softwaremodelle Anpassbar an Domäne und Modellierungszweck Teilprozess Anwendung wird während der Modellierung durchgeführt (z.b. in einem Modell-Review) Teilprozess Spezifikation sollte vorher durchgeführt werden (so früh wie möglich) Basiert auf Modellmetriken, Model Smells und Refactorings (Beispiele für UML-Klassenmodelle in Vorlesung und Übung) Werkzeugunterstützung in Eclipse durch EMF Refactor 6 Software-Evolution WS 2014/2015

7 A structured model quality assurance process Specification process Manager Designer Application process Modeler Reviewer 7 Software-Evolution WS 2014/2015

8 06. November 2014: Versionsverwaltung von Softwareartefakten Warum ist die Versionsverwaltung von Softwareartefakten wichtig? Versions- bzw. Versionierungsprobleme Mittel: Versionskontrolle für Anforderungsdokumente, Modelle, Code, Testdateien, Dokumentationen, etc. Hauptproblem: Wie ermöglicht das Versionsverwaltungssystem den Nutzern Zugang zu gemeinsamen Dokumenten, ohne versehentlich Informationen zu löschen? Lösung: Sperren oder (2-/3-Wege) Mischen (Vor- und Nachteile?) Revisionen, Revisionsbäume (Branches) und Releases Branches zur Bearbeitung von Evolutionsaufgaben bestens geeignet Versionierungsmanagement-Aktivitäten Was versionieren? Rollen? Strategien? Werkzeuge? Versionierung in verschiedenen Entwicklungsprozessen Zentrales Repository, Integration Manager, Leutnant/Diktator 8 Software-Evolution WS 2014/2015

9 SVN vs. Git: Aufbau eines zentralen Repository Ein zentrales Repository für die Arbeitsgruppe z.b. in der Cloud Lokale Arbeitsbereiche oder lokale Repositories 9 Software-Evolution WS 2014/2015

10 13. November 2014: Änderungsverwaltung und Repository-Analyse Motivation für Fehlerverfolgungssysteme (Bugtracker): Unterstützung von Anwendern und Entwicklern in der Protokollierung und im Management von Fehlern (und Feature Requests), die bei der Benutzung von Software auftreten Zweck von Fehlerverfolgungssystemen Downtime reduzieren, Entwicklerproduktivität erhöhen, Kommunikation verbessern, Anwender zufrieden stellen Lebenszyklus eines Bugs unconfirmed, new, assigned, resolved, verified, closed, reopened Was können Analysewerkzeuge erzählen? Evolution von Projektumfang, Entwickleraktivität, Versionierungsaktivität, Bug Reports, Änderungshäufigkeit, etc. Welche Analysewerkzeuge gibt es? 10 Software-Evolution WS 2014/2015

11 Aufbau eines Bug-Reports Obligatorisch Status und Resolution Zusammenfassung Ein Satz Wer hat berichtet? Wem zugeordnet? Bekommt eine Soll den Bug beurteilen und gegebenenfalls beheben Priorität Sollte von Anderen nicht geändert werden. Version Produkt und Komponente Plattform und Betriebssystem Optional Wer ist für die QA zuständig? Schwierigkeitsgrad von unbenutzbar bis kosmetisch CC Liste Wer sollte zusätzlich noch per davon erfahren? Kommentare Anhänge Stack Trace Beispiel Screendump 11 Software-Evolution WS 2014/2015

12 Forward-, Reverse- und Re-Engineering 12 Software-Evolution WS 2014/2015

13 27. November 2014: Der erste Kontakt mit dem System (Programmverstehen 1) Unterscheidung Forward-, Reverse- und Re-Engineering (Folie 12) Was sind Re-Engineering Patterns? Wiederkehrende Lösungen für Probleme bei der Änderung bestehender Softwaresysteme Wie generell beginnen? Die Richtung festlegen Grundsätze festlegen; Womit starten?; Probleme lösen, nicht Symptome; never change a running system ; Eine einfache Lösung suchen; Ständig das Team synchronisieren Wie sich dem System effizient nähern? Der erste Kontakt Über das System reden (mit Entwicklern; Interview während Demo) Das System anschauen (Lies den Code in einer Stunde!; Überflieg die Dokumentation!; Kompiliere und wende das System an!) Wie können Werkzeuge helfen? Welche gibt es? 13 Software-Evolution WS 2014/2015

14 04. Dezember 2014: Wie ist das System-Design? (Programmverstehen 2) Wie das Design identifizieren? Erstes Designverstehen Die persistenten Datenstrukturen verstehen Spekulation über das Design Ableiten von Klassenmodellen (Reverse Engineering) Wichtig sind Abhängigkeiten zwischen relevanten Paketen bzw. Klassen Welche Werkzeuge können dabei unterstützen? Welche Probleme treten dabei auf? Identifizierung von potentiellen Design-Problemen Hilfsmittel: Entwicklungsumgebung mit Metrik-Werkzeug Wonach suchen? Simple und klare Metriken ohne Grenzwerte; Anomalien Was sind Softwaremetriken? Welche Softwaremetriken können verwendet werden? Welche Werkzeugunterstützung gibt es? 14 Software-Evolution WS 2014/2015

15 Objektorientierte Strukturen von einem Datenbankschema ableiten Pro Tabelle eine Klasse. Pro Spalte ein Attribut in der entsprechenden Klasse. Mögliche Schlüsselattribute bestimmen Pro Fremdschlüssel sammeln: Assoziation zwischen den entsprechenden Klassen erzeugen Ableitung hinsichtlich Vererbung: Primärschlüssel tritt als Fremdschlüssel in einer anderen Tabelle auf: Die identifizierte Assoziation kann auch eine Vererbung sein. Tabellen mit gleichen Spaltendefinitionen können eine über mehrere Tabellen verteilte Klassenhierarchie kodieren. Tabellen mit vielen Spalten und optionalen Attributen können eine in einer Tabelle kodierte Klassenhierarchie darstellen. Abgeleitete Struktur mit dem Code abgleichen und ggf. ergänzen 15 Software-Evolution WS 2014/2015

16 Objektorientierte Strukturen aus XML- Format ableiten DTD oder XML-Schema als Grundlage Übersetzungsregeln: Klassen aus XML Elementen ableiten Attribute aus XML Attributen ableiten Assoziationen aus ID/IDREF ableiten Kompositionen aus Containments ableiten Die abgeleitete Klassenstruktur sollte fortlaufend mit den Code-Klassen verglichen werden. 16 Software-Evolution WS 2014/2015

17 18. Dezember 2014: Detailliertes Verständnis (Programmverstehen 3) Obwohl das grobe Design klar ist, Details müssen verstanden werden. Dokumentation des detaillierten Programmverstehens Protokolle gemeinsamer Sitzungen; Berichte über Analysen; Annotation des Codes (kommentarbasiert oder methodenbasiert) Refactoring, um das Design von kryptischem Code zu verstehen Umbenennungen; Doppelten Code eliminieren; Lange Blöcke in private Methoden extrahieren; Lange Methoden zerschlagen; Besser sortieren Welche Objekte arbeiten zur Laufzeit zusammen? Schrittweise Ausführung (typische Nutzungsszenarien; Debugger; auf einen Systemteil fokussieren) Wie können Tests zum Verstehen verwendet werden? Vorhandene Tests zeigen wertvolle Funktionalität; neue Tests zur Evaluierung von Hypothesen Erste Re-Engineering-Schritte: Modell-basiertes Re-Engineering 17 Software-Evolution WS 2014/2015

18 Erkenne interessante Muster im Code Muster zeigen üblicherweise etwas vom Design. Idee: Versuch Muster im Code zu entdecken Design Patterns-spezifische Klassen- und Methodennamen: z.b. Factory, getinstance (Singleton), notify (Observer) Methoden mit Parametertypen von wichtigen Klassen sind wichtig. Sich wiederholende Parametertypen bilden wichtige Links zwischen Objekten. Data Clumps zeigen semantisch zusammenhängende Daten. Konstruktor- oder Factory-Methodenaufrufe: Wann werden Objekte erzeugt? Überschriebene Methoden zeigen, an welchen Stellen spezialisiert wird. super()-aufrufe zeigen, dass Methoden nicht überschrieben werden sollen. 18 Software-Evolution WS 2014/2015

19 15. Januar 2015: Test-First-Ansatz Wie stellt man sicher, dass der Code nach einer Änderung noch läuft? Wie begegnet man mögliche Seiteneffekte einer Änderung? Verwendung von Testsuiten (automatisierte Testfälle) Welche Systemteile sollen getestet werden? Teile, die wir nicht voll verstehen, aber benötigen; Fragile Teile; Neue Teile; Benötigte Systemteile mit Fehlern, Schnittstellen, nicht Implementierungen Wann testen? Wann aufhören zu testen? Inkrementelles Einführen von Tests für diejenigen Systemteile, an denen gearbeitet wird Womit kann systematisch getestet werden? Mit Test-Frameworks wie z.b. JUnit. Wie funktioniert JUnit? Was ist Test-First? Erst die Tests, dann die Implementierung der neuen Funktionalität. 19 Software-Evolution WS 2014/2015

20 Identifikation von repräsentativen Testfällen (datengetrieben) Für eine funktionale Einheit (z.b. Methode): 1. Erstelle ein Modell der Eingabedatenstrukturen 2. Welche Kategorien von Eingabedaten gibt es bezüglich des Verhaltens dieser funktionalen Einheit? 3. Zerlege die Kategorien in Wahlmöglichkeiten 4. Welche Constraints gibt es zwischen den identifizierten Wahlmöglichkeiten? 5. Für jede mögliche Wahlmöglichkeit werden passende Werte gewählt und ein Testfall geschrieben. Dieser enthält auch den Erwartungswert. 20 Software-Evolution WS 2014/2015

21 22. Januar 2015: Migrationsstrategien Was sind grundlegende Lösungsmuster für eine erfolgreiche Migration eines Softwaresystems? Gewinne das Vertrauen der Nutzer und arbeite eng mit Ihnen zusammen Erarbeite eine Strategie für die schrittweise, inkrementelle Migration Direkte Einbindung der Nutzer in die Entwicklung positive Atmosphäre; erste Ergebnisse so früh wie möglich; neue Ergebnisse in regelmäßigen, kurzen Intervallen Wann soll das neue System ausgeliefert werden? Eine erste Version so schnell wie möglich; dann inkrementelle Migration Wie stellt man sicher, dass das neue System funktioniert und auch angenommen wird? Prototyping (Wegwerf-Prototyp oder Weiterentwicklung) Optimiere Funktionalität nur, wenn tatsächlich angebracht 21 Software-Evolution WS 2014/2015

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

23 Datenbrücke Wie können Daten, die sowohl vom Altsystem als auch vom neuen System verarbeitet werden, migriert werden? 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 23 Software-Evolution WS 2014/2015

24 29. Januar 2015: Einführung in die Evolution von Software-Architekturen Was ist eine Software-Architektur? Eine Softwarearchitektur umfasst die Beschreibung von Elementen, aus denen das System gebaut werden soll, sowie Interaktionen zwischen diesen Elementen. Beispiele für Architektur-Design-Muster Model-View-Controller; Inversion of Control Was ist der Unterschied zwischen Refactoring und Architektur- Refactoring? Semantikerhaltende Transformationen von Objektstrukturen Funktionserhaltende Transformationen von Architekturstrukturen Was ist der Unterschied zwischen RCP-Entwicklung in Eclipse 3.x und Eclipse e4? Wie migriert man Eclipse 3.x RCP Anwendungen zu e4? 24 Software-Evolution WS 2014/2015

25 Von einer Zwei-Schichten-Architektur zur serviceorientierten Architektur (SOA) R1- R3: Modell-Code-Relationen 25 Software-Evolution WS 2014/2015

26 05. Februar 2015: Klassenevolution in objektorientierten Systemen Wenn eine Evolution der Datenklassen stattfindet, müssen auch die existierenden Daten angepasst werden. Typische Lösungen: Änderungsvermeidung, Konversion oder Filtern Wie kann man systematisch eine Migration von Daten in einem objektorientierten System durchführen? Siehe nächste Folie Operationen und deren Effekte auf die Instanzebene Keine Effekte; klar definierte Effekte; nicht klar definierte Effekte Beispiel: Evolution eines Metamodells für Petrinetze Wie funktioniert das Werkzeug Edapt zur Migration von Instanzen eines EMF-Metamodells? 26 Software-Evolution WS 2014/2015

27 Änderungen an modellierten Klassenstrukturen 1. Bestimmung von Konsistenzbedingungen Z.B.: alle Objekte eines Typs haben eindeutige Namen, die Klassenhierarchie hat keine Schleifen 2. Erstellung einer Taxonomie aller möglichen Änderungen Z.B.: eine Methode hinzufügen, ein Attribut umbenennen, eine Klasse löschen, eine Oberklasse hinzufügen 3. Für jede Änderungskategorie: Eine präzise Charakterisierung der Effekte auf die Klassenhierarchie, eine Analyse ihrer Anwendung, Einhaltung der Invarianten 4. Reflexion der Effekte auf Objektebene Instanzen von geänderten Klassen werden angepasst. 27 Software-Evolution WS 2014/2015

28 The End [ 28 Software-Evolution WS 2014/2015