Vorlesung Software-Reengineering

Transkript

1 Vorlesung Software-Reengineering Prof. Dr. Rainer Koschke Arbeitsgruppe Softwaretechnik Fachbereich Mathematik und Informatik Universität Bremen Wintersemester 2010/11 Überblick I Refactoring

2 Refactorings: Refactorings I Refactoring Refactoring Bad Smells Refactorings von Fowler Pull-Up Field Extract Method Wann durchführen? Evaluation von Refactorings Kostenschätzung Portfolio-Analyse Bewertung Refactorings Wiederholungsfragen Refactorings: Refactoring Refactorings Definition Refactorings: semantikerhaltende, restrukturierende Code-Transformationen für objekt-orientierte Programme (zur Verbesserung der Wartbarkeit). Beschreibung nach Fowler (2000): Name Anwendbarkeit Motivation mechanische Schritte (die eigentliche Transformation), die von Hand ausgeführt werden Beispiel Sehr viele dieser Refactorings sind genauso auf prozedurale Programme anwendbar.

3 Refactorings: Refactoring Refactoring-Prozess Angestoßen von Änderungswunsch. Prozess (inkrementell, iterativ): 1 Identifikation eines schlechten Geruchs (bad smell) 2 Refactoring 3 Compile & Test 4 Eigentliche Änderung 5 Compile & Test Refactorings: Bad Smells Stink Parade of Bad Smells by Fowler (2000) duplizierter Code lange Methoden große Klassen lange Parameterlisten divergente Änderung eine Klasse wird stets geändert in verschiedener Weise und für unterschiedliche Gründe Schrotflinten-Chirurgie (Shotgun Surgery) kleine Änderungen überall Feature-Neid sehr viele Attribute einer anderen Klasse werden für eine Berechnung benutzt

4 Refactorings: Bad Smells Stink Parade of Bad Smells by Fowler (2000) Datenklumpen (Data Clumps) eine Menge von Datenelementen, die häufig gemeinsam benutzt werden z.b. Attribute einer Klasse, Parameter in Methodensignaturen Fixierung aufs Primitive (Primitive Obsession) einfache Typen werden nicht als Klasse sondern als primitive Datentypen deklariert Switch-Anweisungen händisches dynamisches Binden Parallele Vererbungshierarchien Faule Klassen Klassen, die nichts Nützliches (mehr) tun... Refactorings: Refactorings von Fowler 70 Refactorings von Fowler (2000) Methodenzusammensetzung z.b. Extraktion von Methoden Eigenschaften zwischen Klassen bewegen z.b. Verschiebung von Attributen oder Methoden Organisation von Daten z.b. Verbergung von Attributen Vereinfachung bedingter Ausdrücke z.b. Zerlegung komplexer Bedingungen Vereinfachung von Methodenaufrufen z.b. Separierung von bloßem Zugriff von Manipulation Generalisierungen z.b. Attribute oder Methoden in der Hierarchie auf- oder abwärts bewegen

5 Refactorings: Pull-Up Field Beispiel: Pull-Up Field Gleiches Attribut in Unterklassen wird nach Oberklasse verlegt. Employee Employee Name Salesman Engineer Salesman Engineer Name Name Refactorings: Pull-Up Field Motivation für Pull-Up Field nach Fowler (2000) If subclasses are developed independently, or combined through refactoring, you often find that they duplicate features. In particular, certain fields can be duplicates. Such fields sometimes have similar names but not always. The only way to determine what is going on is to look at the fields and see how they are used by other methods. If they are being used in a similar way, you can generalize them. Doing this reduces duplication in two ways. It removes the duplicate data declaration and allows you to move from the subclassses to the superclass behavior that uses the field.

6 Refactorings: Pull-Up Field Mechanics für Pull-Up Fields 1 Inspect all uses of the candidate fields to ensure they are used in the same way. 2 If the fields do not have the same name, rename the fields so that they have the name you want to use for the superclass field. 3 Compile and test. 4 Create a new field in the superclass. 5 If the fields are private, you will need to protect the superclass field so that the subclasses can refer to it. 6 Delete the subclass fields. 7 Compile and test. 8 Consider using Self Encapsulate Field on the new field. Refactorings: Extract Method Extract Method s t a t i c Order o r d e r ; s t a t i c c h a r name [ ] ; v o i d p r i n t O w i n g ( ) { Enumeration e = e l e m e n t s ( o r d e r ) ; d o u b l e o u t s t a n d i n g = 0. 0 ; // p r i n t banner p r i n t f ( \ n ) ; p r i n t f ( Customer Owes \ n ) ; p r i n t f ( \ n ) ; // c a l c u l a t e o u t s t a n d i n g w h i l e ( hasmoreelements ( e ) ) { Order each = nextelement ( e ) ; o u t s t a n d i n g += getamount ( each ) ; // p r i n t d e t a i l s p r i n t f ( name %s \ n, name ) ; p r i n t f ( amount %s \ n, o u t s t a n d i n g ) ;

7 Refactorings: Extract Method Extract Method: parameterlos // p r i n t banner v o i d printbanner() { p r i n t f ( \ n ) ; p r i n t f ( Customer Owes \ n ) ; p r i n t f ( \ n ) ; v o i d p r i n t O w i n g ( ) { Enumeration e = e l e m e n t s ( o r d e r ) ; d o u b l e o u t s t a n d i n g = 0. 0 ; printbanner ( ) ; // c a l c u l a t e o u t s t a n d i n g w h i l e ( hasmoreelements ( e ) ) { Order each = nextelement ( e ) ; o u t s t a n d i n g += getamount ( each ) ; // p r i n t d e t a i l s p r i n t f ( name %s \ n, name ) ; p r i n t f ( amount %s \ n, o u t s t a n d i n g ) ; Refactorings: Extract Method Extract Method: nur Eingabeparameter // p r i n t d e t a i l s v o i d printdetails ( d o u b l e o u t s t a n d i n g ) { p r i n t f ( name %s \ n, name ) ; p r i n t f ( amount %s \ n, o u t s t a n d i n g ) ; v o i d p r i n t O w i n g ( ) { Enumeration e = e l e m e n t s ( o r d e r ) ; d o u b l e o u t s t a n d i n g = 0. 0 ; p r i n t B a n n e r ( ) ; // c a l c u l a t e o u t s t a n d i n g w h i l e ( hasmoreelements ( e ) ) { Order each = nextelement ( e ) ; o u t s t a n d i n g += getamount ( each ) ; printdetails( o u t s t a n d i n g ) ;

8 Refactorings: Extract Method Extract Method: mit Ausgabeparameter // c a l c u l a t e o u t s t a n d i n g d o u b l e getoutstanding( Enumeration e, d o u b l e o u t s t a n d i n g ) { w h i l e ( hasmoreelements ( e ) ) { Order each = nextelement ( e ) ; o u t s t a n d i n g += getamount ( each ) ; r e t u r n o u t s t a n d i n g ; v o i d p r i n t O w i n g ( ) { Enumeration e = e l e m e n t s ( o r d e r ) ; d o u b l e o u t s t a n d i n g = 0. 0 ; p r i n t B a n n e r ( ) ; o u t s t a n d i n g = getoutstanding( e, o u t s t a n d i n g ) ; p r i n t D e t a i l s ( o u t s t a n d i n g ) ; Refactorings: Extract Method Extract Method: weitere Vereinfachung // c a l c u l a t e o u t s t a n d i n g d o u b l e g e t O u t s t a n d i n g ( ) { Enumeration e = e l e m e n t s ( o r d e r ) ; d o u b l e o u t s t a n d i n g = 0. 0 ; w h i l e ( hasmoreelements ( e ) ) { Order each = nextelement ( e ) ; o u t s t a n d i n g += getamount ( each ) ; r e t u r n o u t s t a n d i n g ; v o i d p r i n t O w i n g ( ) { p r i n t B a n n e r ( ) ; p r i n t D e t a i l s ( g e t O u t s t a n d i n g ( ) ) ;

9 Refactorings: Wann durchführen? Wann sollte man Refactorings durchführen? Refactorings im Kleinen (lokale Änderungen innerhalb weniger Module) Wann immer eine Änderung der betreffenden Code-Stellen ansteht, die ohne Refactoring schwierig ist. Wenn sich eine Code-Stelle als fehlerträchtig oder unnötig kompliziert herausstellt. Wenn eine Code-Stelle permanent auch für verschiedenartige Kundenwünsche angepasst werden muss. Refactorings im Großen/Reengineering (massive Änderungen innerhalb eines Subsystems oder Änderungen in der Architektur) Wenn eine substantielle Erweiterung geplant ist. Wenn das Subsystem mit neuen Subsystemen integriert werden soll. Wenn die Wartbarkeit stark gesunken ist. Refactorings: Evaluation von Refactorings Wie kann Erfolg von Refactorings gemessen werden? Eigentlich ganz einfach (sei P das Programm vor dem Refactoring und P das danach): 1 Man wähle geeigneten Satz von Metriken M. 2 Erfolg = M(P ) > M(P) Aber: Was sind geeignete Metriken? Und wie lässt sich M(P ) schätzen, bevor das Refactoring durchgeführt wird? Was wird das Refactoring kosten und wie lange wird es dauern?

10 Refactorings: Kostenschätzung Kostenschätzung Faktoren Produkt, z.b. relative Wartbarkeit Metriken der Größe (LOC, Function Points) Aufwand des Testens bzw. bisherige Testüberdeckung (für Regressionstest) Anzahl gefundener Fehler (im Test/Feld) und deren Kosten Ressourcen, z.b. verfügbare Werkzeugunterstützung inklusive Aufwand für Anpassung bzw. Entwicklung von Werkzeugen Erfahrung des Wartungspersonals Prozess, z.b. bisheriger Aufwand für Wartung, idealerweise bezogen auf einzelne Aktivitäten Refactorings: Kostenschätzung Kostenschätzung Ideal: Aus den oben genannten Faktoren und den früheren Kosten wird mittels statistischer Analysen ein Kostenmodell entwickelt.

11 Refactorings: Kostenschätzung Alternative Kostenschätzung nach Sneed (1995) Gesamtaufwand = Reengineering-Aufwand + Testaufwand Komplexität Größe [loc] durchschn. Produktivität [loc/pm] RE-Aufwand [pm] = über alle Komponenten Testaufwand = #Testfälle Durchschnittsaufwand-pro-Testfall #Testfälle kann aus zyklomatischer Zahl (McCabe) im Falle der Zweigüberdeckung abgeleitet werden Gewichtung bezüglich Testbarkeit, Testunterstützung, Testumgebung Erfahrungswert: Testaufwand = n RE-Aufwand für 1 n 3 Annahme: Reengineering wird großteils automatisiert. Refactorings: Portfolio-Analyse Wo beginnen? Portfolio-Analyse Zwei Aspekte: relative Wartbarkeit Geschäftswert = Wert der Software Bestimmung des Geschäftswerts... durch Marktanalytiker Marktwert Beitrag zum Profit Werbewirksamkeit... und Softwarearchitekt hängen andere wichtige Systeme davon ab?

12 Refactorings: Portfolio-Analyse Portfolio-Analyse Vergebe 100 Prozentpunkte pro Wertaspekt. Summiere (eventuell mit Gewichtung) die Zeilen für jedes System. System Markwert Profit Werbewert Bewertung A B C D E Summe Refactorings: Portfolio-Analyse Zu sanierende Systeme relative Wart barkeit gut ausreichend D C schlecht sekundäre Reengineering kandidaten A primäre Reengineering kandidaten E B miserabel Aufgabe oder Wrapping F Wrapping oder Neuentwicklung niedrig Geschäftswert hoch

13 Refactorings: Bewertung Refactorings Bewertung Refactorings Teilweise gut durch Werkzeuge unterstützt: Refactoring Browser für Smalltalk Eclipse/JDT für Java Eclipse/CDT für C/C++ Ansonsten werden die Mechanics von Hand durchgeführt Die Beurteilung, wann und welches Refactoring angebracht ist, obliegt dem Menschen. Hinter Compile & Test kann sich viel Arbeit verbergen. Zum Buch von Fowler (2000): Beschreibung ist zu informell für eine automatisierte Transformation, aber zumindest eine gute Checkliste. Die genauen Vorbedingungen sind nicht ausreichend angegeben. Refactorings: Wiederholungsfragen Wiederholungs- und Vertiefungsfragen I Welche Schritte sind beim Refactoring durchzuführen? Was ist ein Bad Smell? Beispiele? Wie lassen sich Bad Smells erkennen? Wie kann man die Reihenfolge der zu sanierenden Systeme festlegen?

14 Refactorings: Wiederholungsfragen 1 Fowler 2000 Fowler, Martin: Refactoring: Improving the Design of Existing Code. Addison-Wesley, Sneed 1995 Sneed, Harry: Planning the Reengineering of Legacy Systems. In: IEEE Software (1995), January. beschreibt die Planung von Reengineering-Projekten