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

Transkript

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

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 2014/2015

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 Softwareentwicklungsprozesse 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 2014/2015

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 2014/2015

5 Informationsquellen im Reverse Engineering Lesen der vorhandenen Dokumentation Lesen des Quellcodes Anwendung 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 2014/2015

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. [Demeyer et al.] 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 6 Software-Evolution WS 2014/2015

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 2014/2015

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

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 2014/2015

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

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 2014/2015

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 2014/2015

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 2014/2015

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 2014/2015

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

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

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 2014/2015

18 Über das System reden: Diskussion mit den Entwicklern 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 2014/2015

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 2014/2015

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

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 2014/2015

22 Die Software anwenden Problem 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 2014/2015

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

24 Beispiel: Evolutionsaufgabe für EMF Refactor 1. Entferne die Möglichkeit eines Preview bei Ausführung eines Refactorings. Grund: Die baumbasierte Darstellung der Differenzen ist bei grafischen oder textuellen Modellen schwer zu verstehen 2. Füge einem Refactoring eine Beschreibung hinzu. Bisher: Bis auf einen aussagekräftigen Namen bietet ein Refactoring zur Zeit keine Beschreibung seines Zweckes bzw. seiner Funktionsweise an. 3. Ergänze den Generierungsprozess eines Refactorings um die Möglichkeit, die Henshin-Dateien neu anzulegen. Bisher: Die Henshin-Dateien müssen bereits vorhanden sein 24 Software-Evolution WS 2014/2015

25 Architektur von EMF Refactor (1) Specification Language Generation module Application module metrics, smells, refactorings extension points Eclipse Modeling Framework (EMF) 25 Software-Evolution WS 2014/2015

26 Architektur von EMF Refactor (2) 26 Software-Evolution WS 2014/2015

27 Architektur von EMF Refactor (3) 27 Software-Evolution WS 2014/2015

28 Eclipse Repositories von EMF Refactor Core: allgemeine Dinge, wie z.b. Menus Je ein Repository für die unterstützten Techniken (Metrics, Smells, Refactoring) Examples: Konkrete Techniken für UML 2.5 und Ecore-Modelle 28 Software-Evolution WS 2014/2015

29 Plugin-Struktur der Refactoring-Komponenten 29 Software-Evolution WS 2014/2015

30 Pakete von org.eclipse.emf.refactor.refactoring.henshin 30 Software-Evolution WS 2014/2015

31 Beispiel: Evolutionsaufgabe für EMF Refactor erste Einschätzung der Änderungs-Stellen 1. Entfernung des Preview Plugin: org.eclipse.emf.refactor.refactoring.runtime Klasse: org..runtime.ltk.ui.refactoringpreviewviewer.java 2. Beschreibung des Refactorings Plugin: org.eclipse.emf.refactor.refactoring Extension Point: org.eclipse.emf.refactor.refactorings Klasse: org..refactoring.core.refactoring.java 3. Anlage der Henshin-Dateien Plugin: org.eclipse.emf.refactor.refactoring.henshin Klasse: org..henshin.ui.henshintransformationwizardpage.java Klasse: org..henshin.managers.henshingenerationmanager.java 31 Software-Evolution WS 2014/2015

32 Zusammenfassung und Literatur 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. Literatur: Serge Demeyer, Stephane Ducasse, Oscar Nierstrasz: Object-Oriented Reengineering Patterns, 2013, Kap. 1 3, online verfügbar unter 32 Software-Evolution WS 2014/2015

33 Werkzeuge und Quellen im WWW EMF Refactor Website: EMF Refactor Tutorial: EMF Refactor Architecture: EMF Refactor Repositories: Henshin Website: Eclipse Metrics2 Project: 33 Software-Evolution WS 2014/2015