Programmverstehen 2: Wie ist das System-Design? · PDF fileeiner Tabelle kodierte Klassenhierarchie darstellen. ... • Norman Fenton, James Bieman: Software Metrics - A Rigorous and

Programmverstehen 2: Wie ist das System-Design?
Dr. Thorsten Arendt Marburg, 03. Dezember 2015

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

Viele Designkonzepte und unzhlige Wege, sie zu reprsentieren. Groe Teile des Quellcode haben nichts mit dem Design zu tun.
Techniken, um das Design eines Systems zu identifizieren:
Die persistenten Datenstrukturen verstehen Spekulation ber das Design Ableiten von Klassenmodellen Identifizierung von potentiellen Design-Problemen
berblick
Probleme

Persistente Daten sind wertvoll. Deshalb sollten sie verstanden werden.
Welche Daten sind persistent? Welche persistenten Daten sind nicht so wertvoll?
Wie werden die persistenten Daten gespeichert? In einer Datenbank: Datenbankschema betrachten In einer Datei: Ein-/Ausgabeformat betrachten
Wie werden persistente Daten im Hauptspeicher gehalten?
Diese Datenhaltung kann sich erheblich vom Speicherformat unterscheiden. Warum?
Die persistenten Daten verstehen

Pro Tabelle eine Klasse. Pro Spalte ein Attribut in der entsprechenden Klasse. Mgliche Schlsselattribute bestimmen
Pro Fremdschlssel: Assoziation zwischen den entsprechenden Klassen erzeugen
Ableitung hinsichtlich Vererbung: Primrschlssel tritt als Fremdschlssel in einer anderen Tabelle auf:
Die identifizierte Assoziation kann auch eine Vererbung sein. Tabellen mit gleichen Spaltendefinitionen knnen eine ber mehrere
Tabellen verteilte Klassenhierarchie kodieren. Tabellen mit vielen Spalten und optionalen Attributen knnen eine in
einer Tabelle kodierte Klassenhierarchie darstellen.
Objektorientierte Strukturen von einem Datenbankschema ableiten

Beispiel: DB-Schema zu Klassenmodell Tabellen mit Fremdschlssel
Groe Tabelle optionale Spalten
Tabellen mit gemeinsamen Spalten
[Demeyer et al.]

Die aus einem Datenbankschema abgeleitete Klassenstruktur kann noch zu klein sein.
Es knnen Klassen fehlen, da sie keine neuen Attribute definieren. Entgegengesetzte Assoziationen knnen vereinigt werden. N:M-Beziehungen werden als Assoziationsklassen identifiziert. Rollen, Sichtbarkeiten und Multiplizitten mssen eventuell noch
ergnzt werden.
Das erstellte Klassenmodell muss fortlaufend verifiziert werden.
Durch den Code Durch die in der Datenbank gehaltenen Daten
Objektorientierte Struktur mit dem Code abgleichen

DTD oder XML-Schema als Grundlage
bersetzungsregeln:
Klassen aus XML Elementen ableiten Attribute aus XML Attributen ableiten
Namen mit entsprechenden Code-Klassen vergleichen Typen aus entsprechenden Code-Klassen bernehmen
Assoziationen aus ID/IDREF ableiten Kompositionen aus Containments ableiten
Die abgeleitete Klassenstruktur sollte fortlaufend mit den Code-Klassen verglichen werden.
Objektorientierte Strukturen aus XML-Format ableiten

Beispiel: XML-Format des Metriken-Exports in EMF Refactor (1)

Beispiel: XML-Format des Metriken-Exports in EMF Refactor (2)

1. Ansatz Komplettes Klassendiagramm aus den Code
automatisch ableiten
2. Ansatz Das Design lernen Hypothesen ber das Design aufstellen und
am Code berprfen
ber das Design spekulieren
Problem Aus dem Code ein Designmodell ableiten

Fhre eine neue Unit ein, die eine Menge referenzierter Units sooft wie mglich anwendet (LayerUnit) .
Grund: Oftmals soll eine Regel-Menge (bzw. die darin enthaltenen Regeln) solange ausgefhrt werden, bis keine Regel mehr angewendet werden kann (z.B. in Grammatiken).
Bisher: Wrappen der Regeln in einer IndependentUnit, die innerhalb einer LoopUnit ausgefhrt wird.
Beispiel: Komplette Ausfhrung eines Aktivittendiagramms
Beispiel: Evolutionsaufgabe fr Henshin

Plugin-Struktur der Henshin-Komponenten

Beispiel: Evolutionsaufgabe fr Henshin erste Einschtzung 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

Beispiel: Abhngigkeiten ausgewhlter Komponenten von Henshin (1)
[Architexa]

[Architexa]

Beispiel: Reverse-Engineering der Klasse UnitApplicationImpl (1) [Architexa]

Beispiel: Reverse-Engineering der Klasse UnitApplicationImpl (2)
[UMLLab]

Es gibt keinen einfachen Weg, problematisches Design von gutem zu unterscheiden.
Um ein Design-Problem zu erkennen, muss man die innere Struktur verstehen.
Hilfsmittel / Voraussetzungen Entwicklungsumgebung mit Metrik-Werkzeuge Ein grobes Verstndnis des Systems
Wonach sollen wir suchen? Simple und klare Metriken ohne Grenzwerte Anomalien, fr oder gegen die argumentiert werden sollte Dazu muss auch der Code angeschaut werden.
Identifizierung potentieller Design-Probleme

Was sind Softwaremetriken?
Wdh.: Metriken und Qualittssicherung
Softwaremetriken messen Qualitt. besser :
Softwaremetriken definieren, wie Kenngren der Software oder des Softwareentwicklungsprozesses gemessen werden.
A function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which software
possesses a given attribute that affects its quality.
IEEE Standard 1061 1998 (software quality metric):

Vor- und Nachteile von Softwaremetriken
Softwareentwicklung wird vorhersagbarer.
Beurteilung von Test- und Wartungsaufwand
Erzieherischer Effekt auf die Entwickler
Untersttzen die Suche nach Problemen im Code
Vorteile Nachteile
Mglicherweise Messen ohne Ziel
Nutzen von Metriken oft nicht klar
Abwehrhaltung der Entwickler
Subjektiver Einfluss der Prfer mglich
Viele Eigenschaften nicht direkt messbar

DIT Depth of Inheritance Tree Anzahl der Oberklassen: Je mehr, desto fehleranflliger
NOC Number Of Children Anzahl der direkten Unterklassen: Je mehr, desto besser der Code
(hohe Wiederverwendung).
RFC Response For a Class Anzahl der eigenen + aufgerufenen Methoden: Je mehr, desto
fehleranflliger
WMC Weighted Method per Class Anzahl der definierten Methoden: Je mehr, desto fehleranflliger
CBC Coupling Between Classes Anzahl der benutzten Klassen: Je mehr, desto fehleranflliger
Objektorientierte Softwaremetriken

Hohe Komplexitt im Code McCabe, viele geschachtelte Blcke, LOC
Starke Kopplung der Module Objektorientierte Softwaremetriken (Coupling, DIT, etc.)
Beispiel: Verdchtige Module
[Metrics2]

Anzahl linear unabhngiger Pfade auf dem Kontrollflussgraphen eines Moduls
Anzahl der binren Verzweigungen plus 1
je komplexer das Programm, desto hher das Risiko
nicht uneingeschrnkt fr OO-Programme einsetzbar
Beispiel: McCabe Komplexittsma (1)
[Metrics2]

Schlechte McCabe Komplexitt von 13, aber eigentlich bersichtlich
Beispiel: McCabe Komplexittsma (2)

Maximale Anzahl der Schachteln um geschachtelte Anweisungen
Liefert ein Indiz zur Lesbarkeit und Verstndlichkeit
Vorteil: leicht messbar
Nachteil: erfassen wenig von der algorithmischen Struktur
Beispiel: Schachtelungstiefe (1)
[Metrics2]

Beispiel: Schachtelungstiefe (2)
Ist diese sehr tiefe Schachtelung (8) vermeidbar?

Zusammenhang von Verstehen-Patterns
[Demeyer et al.]

Die Hauptaufgabe von Reverse Engineering ist das Erkennen des System-Designs.
Reverse-Engineering-Tools helfen nur bedingt. Zu viele Implementierungsdetails Manuelle Erstellung des Designmodells ist oft effektiver
Persistente Daten sind ein guter Hinweis auf die wichtigen Daten.
Ein erster Blick auf Design-Prob

Documents

Programmverstehen 2: Wie ist das System-Design? · PDF fileeiner Tabelle kodierte Klassenhierarchie darstellen. ... • Norman Fenton, James Bieman: Software Metrics - A Rigorous and