Programmverstehen 1: Der erste Kontakt mit dem System · •Die traditionelle Softwareentwicklung...

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


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


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


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


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.]


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“


Forward-, Reverse- und Re-Engineering

[Demeyer et al.]

• 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


Re-Engineering Patterns


Gruppierung von Re-Engineering Patterns

[Demeyer et al.]

– 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


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.


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.


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


Weitere Richtungs-Patterns


Zusammenhang von Richtungs-Patterns

[Demeyer et al.]


Gruppierung von Re-Engineering Patterns

[Demeyer et al.]

• Softwaresysteme

sind häufig groß

und Zeit ist kostbar.

• Wie nähert man

sich einem System

möglichst effizient?


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?


Ü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.


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.


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)


Ü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.


Die Software anwenden


Zusammenhang von Kontakt-Patterns

[Demeyer et al.]

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


Beispiel: Evolutionsaufgabe für Henshin


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


Plugin-Struktur der Henshin-Komponenten


Pakete und Abhängigkeiten von

org.eclipse.emf.henshin.interpreter

[Metrics2]


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


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/


Literatur und Werkzeuge

http://scg.unibe.ch/download/oorp/

http://www.eclipse.org/henshin/

http://projects.eclipse.org/projects/modeling.emft.henshin/developer

http://metrics2.sourceforge.net/

Programmverstehen 1: Der erste Kontakt mit dem System · •Die traditionelle Softwareentwicklung...

Documents

Transcript of Programmverstehen 1: Der erste Kontakt mit dem System · •Die traditionelle Softwareentwicklung...