View
1
Download
0
Category
Preview:
Citation preview
Programmverstehen 1:
Der erste Kontakt mit dem System
Dr. Thorsten Arendt
Marburg, 19. November 2015
• 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
Überblick
• 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
3 Software-Evolution WS 2015/2016
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.”
[Demeyer et al.]
• 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
4 Software-Evolution WS 2015/2016
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.”
[Demeyer et al.]
• 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
Informationsquellen im Reverse Engineering
• 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 2015/2016
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.]
7 Software-Evolution WS 2015/2016
Der Weg kann steinig sein…
• Unzureichende
Dokumentation
• Keine gute Architektur
• Zu wenig Modularität
• Duplizierter Code
• Duplizierte Funktionalität
Im Großen Im Kleinen
• Falsche Verwendung von
Vererbung
• Fehlende Vererbung
• Operationen in falschen
Klassen
• Verletzung von Kapselungen
• Klassen als „Auffanglager“
• 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
Re-Engineering Patterns
– 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
Setting Direction: Die Richtung festlegen
Probleme
• 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
Grundsätze festlegen
• 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
Mit welchen Problemen sollten wir starten?
• 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
Weitere Richtungs-Patterns
• Softwaresysteme
sind häufig groß
und Zeit ist kostbar.
• Wie nähert man
sich einem System
möglichst effizient?
17 Software-Evolution WS 2015/2016
First Contact: Der erste Kontakt
Problem
• Ü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
• 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
Über das System reden: Diskussion mit den
Entwicklern
• 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
Lies den gesamten Code in einer Stunde!
• 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
Checkliste für den ersten Code-Kontakt
• 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
Überflieg die Dokumentation!
• 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
Die Software anwenden
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
Beispiel: Evolutionsaufgabe für Henshin
25 Software-Evolution WS 2015/2016
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
27 Software-Evolution WS 2015/2016
Pakete und Abhängigkeiten von
org.eclipse.emf.henshin.interpreter
[Metrics2]
28 Software-Evolution WS 2015/2016
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
• 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
Zusammenfassung
• Literatur:
– Serge Demeyer, Stephane Ducasse, Oscar Nierstrasz:
Object-Oriented Reengineering Patterns, 2013, Kap. 1 – 3,
online verfügbar unter http://scg.unibe.ch/download/oorp/
• Werkzeuge:
– Henshin Website: http://www.eclipse.org/henshin/
– Henshin Repository: http://projects.eclipse.org/projects/modeling.emft.henshin/developer
– Eclipse Metrics2 Project: http://metrics2.sourceforge.net/
30 Software-Evolution WS 2015/2016
Literatur und Werkzeuge
Recommended