If you can't read please download the document
Upload
dinhnga
View
226
Download
6
Embed Size (px)
Citation preview
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
3 Software-Evolution WS 2015/2016
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?
4 Software-Evolution WS 2015/2016
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.
5 Software-Evolution WS 2015/2016
Objektorientierte Strukturen von einem Datenbankschema ableiten
6 Software-Evolution WS 2015/2016
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
7 Software-Evolution WS 2015/2016
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.
8 Software-Evolution WS 2015/2016
Objektorientierte Strukturen aus XML-Format ableiten
9 Software-Evolution WS 2015/2016
Beispiel: XML-Format des Metriken-Exports in EMF Refactor (1)
10 Software-Evolution WS 2015/2016
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
11 Software-Evolution WS 2015/2016
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
12 Software-Evolution WS 2015/2016
Beispiel: Evolutionsaufgabe fr Henshin
13 Software-Evolution WS 2015/2016
Plugin-Struktur der Henshin-Komponenten
14 Software-Evolution WS 2015/2016
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
15 Software-Evolution WS 2015/2016
Beispiel: Abhngigkeiten ausgewhlter Komponenten von Henshin (1)
[Architexa]
16 Software-Evolution WS 2015/2016
Beispiel: Abhngigkeiten ausgewhlter Komponenten von Henshin (2)
[Architexa]
17 Software-Evolution WS 2015/2016
Beispiel: Abhngigkeiten ausgewhlter Komponenten von Henshin (3)
[Architexa]
18 Software-Evolution WS 2015/2016
Beispiel: Reverse-Engineering der Klasse UnitApplicationImpl (1) [Architexa]
19 Software-Evolution WS 2015/2016
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.
20 Software-Evolution WS 2015/2016
Identifizierung potentieller Design-Probleme
Was sind Softwaremetriken?
21 Software-Evolution WS 2015/2016
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):
22 Software-Evolution WS 2015/2016
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
23 Software-Evolution WS 2015/2016
Objektorientierte Softwaremetriken
Hohe Komplexitt im Code McCabe, viele geschachtelte Blcke, LOC
Starke Kopplung der Module Objektorientierte Softwaremetriken (Coupling, DIT, etc.)
24 Software-Evolution WS 2015/2016
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
25 Software-Evolution WS 2015/2016
Beispiel: McCabe Komplexittsma (1)
[Metrics2]
Schlechte McCabe Komplexitt von 13, aber eigentlich bersichtlich
26 Software-Evolution WS 2015/2016
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
27 Software-Evolution WS 2015/2016
Beispiel: Schachtelungstiefe (1)
[Metrics2]
28 Software-Evolution WS 2015/2016
Beispiel: Schachtelungstiefe (2)
Ist diese sehr tiefe Schachtelung (8) vermeidbar?
29 Software-Evolution WS 2015/2016
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