Programmverstehen 1: Der erste Kontakt mit dem System. Dr. Thorsten Arendt Marburg, 19. November 2015

Transkript

1 Programmverstehen 1: Der erste Kontakt mit dem System Dr. Thorsten Arendt Marburg, 19. November 2015

2 Überblick Was ist Forward-, Reverse- und Re-Engineering? Was sind Re-Engineering Patterns? Wie nähere ich mich einem unbekannten Softwaresystem? Die Richtung festlegen Der erste Kontakt Erstes Verstehen Erkennen des Designs Mehr Detailverständnis 2 Software-Evolution WS 2015/2016

3 Forward-Engineering Forward Engineering is the traditional process of moving from high-level abstractions and logical, implementation-independent designs to the physical implementation of a system. Die traditionelle Softwareentwicklung von den Anforderungen zur Implementierung. Verwendung eines Vorgehensmodells bzw. eines bestimmten Softwareentwicklungsprozesses meist iterativ, z.b. Spiralmodell von Boehm oder V-Modell XT oft (insbesondere in OSS) agil, z.b. Scrum, XP Abnehmendes Abstraktionsniveau [Demeyer et al.] 3 Software-Evolution WS 2015/2016

4 Reverse Engineering Reverse Engineering is the process of analyzing a subject system to identify the system s components and their interrelationships and create representations of the system in another form or at a higher level of abstraction. Entgegengesetzte Richtung zum Forward Engineering Die Analyse eines Softwaresystems mit dem Ziel, das System- Design zu erkennen. Anwendung von Reverse Engineering beim Versuch, die Arbeitsweise der Software zu verstehen als Vorbereitung eines Re-Engineering, z.b. durch Re-Dokumentieren der Software oder Identifizierung potentieller Probleme Zunehmendes Abstraktionsniveau [Demeyer et al.] 4 Software-Evolution WS 2015/2016

5 Informationsquellen im Reverse Engineering Lesen der vorhandenen Dokumentation Lesen des Quellcodes Anwenden der Software Interviews mit den Benutzern und/oder Entwicklern Implementieren und Ausführen von Testfällen Erstellen und Analysieren von (Ausführungs-) Traces Benutzung von Werkzeugen zum Erstellen von abstrakteren Ansichten des Quellcodes und bestimmter Traces Verlaufsanalyse der Versionierung der Software 5 Software-Evolution WS 2015/2016

6 Re-Engineering Reengineering... is the examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form. Transformation einer konkreten Implementierung in eine andere konkrete Implementierung Währenddessen werden abstrakte Artefakte erstellt Re-Engineering ist Reverse Engineering, Evolution und Forward Engineering Fragestellung: Was muss geändert und was muss ersetzt werden? Dabei treten häufig ähnliche technische Probleme auf [Demeyer et al.] 6 Software-Evolution WS 2015/2016

7 Der Weg kann steinig sein Im Großen Unzureichende Dokumentation Keine gute Architektur Zu wenig Modularität Duplizierter Code Duplizierte Funktionalität Im Kleinen Falsche Verwendung von Vererbung Fehlende Vererbung Operationen in falschen Klassen Verletzung von Kapselungen Klassen als Auffanglager 7 Software-Evolution WS 2015/2016

8 Forward-, Reverse- und Re-Engineering [Demeyer et al.] 8 Software-Evolution WS 2015/2016

9 Re-Engineering Patterns Patterns wurden ursprünglich in der Architektur eingesetzt, um verschiedene physikalische Strukturen systematisch zu entwickeln Jeder Aspekt wird als wiederkehrendes Muster dargestellt Anwendung einer auf die spezifischen Gegebenheiten zugeschnittenen generellen Lösung Erste Anwendung in der Softwareentwicklung durch Beschreibung wiederkehrender Lösungen für Design-Probleme (Design Patterns) Aber auch: Anwendung in Design- und Entwicklungsprozess Re-Engineering Patterns als wiederkehrende Lösungen für Probleme bei der Änderung bestehender Softwaresysteme 9 Software-Evolution WS 2015/2016

10 Gruppierung von Re-Engineering Patterns [Demeyer et al.] 10 Software-Evolution WS 2015/2016

11 Setting Direction: Die Richtung festlegen Probleme Zu viele Details: technische und prozessspezifische Wie sollen die Prioritäten gesetzt werden? Kommunikation mit dem anwesenden bzw. abwesenden Entwicklerteam Schwierige Entscheidungen: Einpacken, Ändern oder Neuschreiben von problematischen Altkomponenten Zu weitreichendes Re-Engineering 11 Software-Evolution WS 2015/2016

12 Grundsätze festlegen Prioritäten im Team festlegen Management möchte geringe Re-Engineering-Kosten. Nutzer möchten bessere Funktionalität. Entwickler möchten einen einfachen Job, aber den Job auch nicht verlieren. Wer ist wofür zuständig? Kann bezüglich der Re-Engineering-Aufgaben eventuell am Anfang noch nicht geklärt werden. Aber: Alle sind für die Evaluation (Testen, Debugging, etc.) zuständig. Zumindest ein Teammitglied sollte den Überblick über die Systemarchitektur behalten. 12 Software-Evolution WS 2015/2016

13 Mit welchen Problemen sollten wir starten? Mit den Problemen, die den Anwendern besonders wichtig sind. Wie erkennen wir, was wichtig ist? Das Geschäftsmodell erkennen Messbare Ziele bestimmen (z.b. bessere Antwortzeiten, schneller mit neuen Features auf dem Markt, etc.) Change Logs erzählen, welche Aktivitäten die wichtigsten waren. Was, wenn das wichtigste Problem zu groß ist? Zerteile es in kleinere, die in kurzer Zeit bearbeitet werden können. 13 Software-Evolution WS 2015/2016

14 Weitere Richtungs-Patterns Löse Probleme, nicht Symptome Anwender haben ihre eigene Sicht auf das System. Such das Problem hinter den Symptomen. Was nicht kaputt ist, sollte nicht angefasst werden. Kaputt ist, was nicht korrekt funktioniert, oder den Anforderungen nicht gerecht wird. Auch wenn es nicht schön ist Such eine einfache Lösung Besser eine einfache, spezifische Lösung als eine generelle, komplexe Lösung Synchronisiere das Team Kurze regelmäßige Treffen, um Informationen und Probleme auszutauschen sowie die weitere Richtung zu besprechen 14 Software-Evolution WS 2015/2016

15 Zusammenhang von Richtungs-Patterns [Demeyer et al.] 15 Software-Evolution WS 2015/2016

16 Gruppierung von Re-Engineering Patterns [Demeyer et al.] 16 Software-Evolution WS 2015/2016

17 First Contact: Der erste Kontakt Problem Softwaresysteme sind häufig groß und Zeit ist kostbar. Wie nähert man sich einem System möglichst effizient? Über das System reden Diskussion mit den Entwicklern Interview während einer Systemdemonstration Das System anschauen Lies den gesamten Code in einer Stunde! Überflieg die Dokumentation! Kompilation des Systems 17 Software-Evolution WS 2015/2016

18 Über das System reden: Diskussion mit den Entwicklern Ziel: In welchem Zustand ist das Projekt? Typische Fragen: Was war der einfachste/schwierigste Bug in letzter Zeit? Wie werden Bugs/Features gesammelt/priorisiert? Wer entscheidet was? Wie funktioniert die Qualitätssicherung? Wer ist seit wann im Team? Wie gut ist der Code/die Dokumentation? 18 Software-Evolution WS 2015/2016

19 Lies den gesamten Code in einer Stunde! Voraussetzungen: Die Programmiersprache ist bekannt. Die Evolutionsaufgaben sind klar. Begleitende Fragen: Ist das Re-Engineering möglich? Welche Module (Pakete, Klassen) sind wichtig für die gestellten Evolutionsaufgaben? Gibt es Code Smells? Welche Teile sollten weiter untersucht werden? Ergebnis ist ein kurzen Bericht über die gewonnenen Eindrücke. 19 Software-Evolution WS 2015/2016

20 Checkliste für den ersten Code-Kontakt Was ist die Paketstruktur? Test-Suiten geben über die Funktionalität von Modulen Aufschluss. Klassen oben in der Hierarchie zeigen Abstraktionen, untere Klassen Variationen Singleton Patterns zeigen Konstanten des Systems Abstrakte Klassen und Methoden zeigen Designentscheidungen. Kommentare beschreiben Designentscheidungen, sind aber nicht immer zuverlässig. 20 Software-Evolution WS 2015/2016

21 Überflieg die Dokumentation! Begleitende Fragen: Welche Teile sind nützlich? Welche nicht? Für wen ist welche Dokumentation geschrieben? Schreib einen kurzen Bericht über die gewonnenen Informationen! Liste der nützlichen Teile (Anforderungsspezifikation, gewünschte Features, wichtige Constraints, Designmodelle, Benutzer- /Entwicklerhandbuch) Wie aktuell sind sie? (Versionsnummer, Datum) 21 Software-Evolution WS 2015/2016

22 Die Software anwenden Probleme Welche sind die typischen Benutzungsszenarien? Welche Features sind relevant, welche nicht? Vorgehen Einen Benutzer das System demonstrieren lassen. Ein Video anschauen/ein Tutorial lesen Das System selbst benutzen. 22 Software-Evolution WS 2015/2016

23 Zusammenhang von Kontakt-Patterns [Demeyer et al.] 23 Software-Evolution WS 2015/2016

24 Beispiel: Evolutionsaufgabe für Henshin Führe eine neue Unit ein, die eine Menge referenzierter Units sooft wie möglich anwendet (LayerUnit). Grund: Oftmals soll eine Regel-Menge (bzw. die darin enthaltenen Regeln) solange ausgeführt werden, bis keine Regel mehr angewendet werden kann (z.b. in Grammatiken). Bisher: Wrappen der Regeln in einer IndependentUnit, die innerhalb einer LoopUnit ausgeführt wird. Beispiel: Komplette Ausführung eines Aktivitätendiagramms 24 Software-Evolution WS 2015/2016

25 Eclipse Git-Repository des Henshin-Projekts Dokumentation mit verschiedenen Beispielen Feature-Projekt zum Bündeln der Plugins Update-Site für die Installation Plugin-Projekte Verschiedene Skripte unterschiedlicher Funktionalität 25 Software-Evolution WS 2015/2016

26 Plugin-Struktur der Henshin-Komponenten 26 Software-Evolution WS 2015/2016

27 Pakete und Abhängigkeiten von org.eclipse.emf.henshin.interpreter [Metrics2] 27 Software-Evolution WS 2015/2016

28 Beispiel: Evolutionsaufgabe für Henshin erste Einschätzung der Änderungs-Stellen 1. Anpassung des Modells Plugin: org.eclipse.emf.henshin.model Modell model/henshin.ecore erweitern und Code neu generieren 2. Anpassung der Editoren Plugin: org.eclipse.emf.henshin.edit/editor Plugin: org.eclipse.emf.henshin.diagram Editoren erneut generieren bzw. manuell anpassen (z.b. Icons) 3. Anpassung des Interpreters Plugin: org.eclipse.emf.henshin.interpreter Klasse: org..henshin.interpreter.impl.unitapplicationimpl.java 28 Software-Evolution WS 2015/2016

29 Zusammenfassung Software Evolution funktioniert nur mit Reverse Engineering. Bevor man ein Programm ändern kann, muss man es verstehen. Dazu muss man das Design hinter einem Programm erkennen. Re-Engineering Patterns helfen, ein Programm systematisch und effizient zu verstehen und zu ändern. Evolutionsaufgabe für Henshin: Einführung einer LayerUnit Erste Einschätzung der betroffenen Änderungsstellen in den einzelnen Komponenten von Henshin 29 Software-Evolution WS 2015/2016

30 Literatur und Werkzeuge Literatur: Serge Demeyer, Stephane Ducasse, Oscar Nierstrasz: Object-Oriented Reengineering Patterns, 2013, Kap. 1 3, online verfügbar unter Werkzeuge: Henshin Website: Henshin Repository: Eclipse Metrics2 Project: 30 Software-Evolution WS 2015/2016