Vorlesung Software-Reengineering

Transkript

1 Vorlesung Software-Reengineering Prof. Dr. Rainer Koschke Arbeitsgruppe Softwaretechnik Fachbereich Mathematik und Informatik Universität Bremen Wintersemester 2009/10

2 Überblick I 1 Refactoring

3 Refactorings I 1 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 Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

4 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. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

5 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 Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

6 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 Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

7 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... Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

8 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 Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

9 Beispiel: Pull-Up Field Gleiches Attribut in Unterklassen wird nach Oberklasse verlegt. Employee Employee Name Salesman Name Engineer Name Salesman Engineer Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

10 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. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

11 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. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

12 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 ) ; Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

13 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 ) ; Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

14 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 ) ; Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

15 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 ) ; Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

16 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 ( ) ) ; Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

17 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. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

18 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? Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

19 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 Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

20 Kostenschätzung Ideal: Aus den oben genannten Faktoren und den früheren Kosten wird mittels statistischer Analysen ein Kostenmodell entwickelt. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

21 Alternative Kostenschätzung nach Sneed (1995) Gesamtaufwand = Reengineering-Aufwand + Testaufwand Komplexität Größe [loc] RE-Aufwand [pm] = durchschn. Produktivität [loc/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. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

22 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? Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

23 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 Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

24 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 Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

25 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. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

26 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? Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27

27 Fowler 2000 Fowler, Martin: Refactoring: Improving the Design of Existing Code. Addison-Wesley, 2000 Sneed 1995 Sneed, Harry: Planning the Reengineering of Legacy Systems. In: IEEE Software (1995), January. beschreibt die Planung von Reengineering-Projekten Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 27