Vorlesung Software-Reengineering Prof. Dr. Rainer Koschke Arbeitsgruppe Softwaretechnik Fachbereich Mathematik und Informatik Universit¨ at Bremen

Wintersemester 2007/08

¨ Uberblick I

Einf¨ uhrung in das Software-Reengineering

Einf¨uhrung in das Software-Reengineering

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

3/1

Einf¨ uhrung in das Software-Reengineering

Organisatorisches

Vorlesung: montags, 10:15 - 11:45 Uhr, Raum MZH 5210 ¨ Vorlesung/Ubung (alternierend): donnerstags, 8:15 - 9:45 Uhr, Raum MZH 5210 Erreichbar: OAS, Telefon 218-9671, [email protected] Sprechstunde nach Vereinbarung Video im Netz http://mlecture.uni-bremen.de Literatur: Folien zur Vorlesung und verwendete Artikel http://www.informatik.uni-bremen.de/st/lehredetails. php?id=&lehre id=307 Reengineering-Bibliographie: http://www.iste.uni-stuttgart.de/ps/reengineering/

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

4/1

Einf¨ uhrung in das Software-Reengineering

Scheinbedingungen

Modulpr¨ ufung: m¨ undliche Pr¨ ufung ansonsten 1

erfolgreiche Bearbeitung von vier praktischen Aufgaben: 1 2 3 4

2

Qualit¨ atsanalyse (quellcodenah) Refactoring/Transformation Architekturpr¨ ufung Merkmalsuche

Fachgespr¨ach

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

5/1

WS 2007/2008

6/1

Einf¨ uhrung in das Software-Reengineering

Lernziele

Grundlegende Begriffe ¨ Ubersicht u ¨ber die Gebiete des Reengineerings Abgrenzung zum traditionellen Software-Engineering

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

Einf¨ uhrung in das Software-Reengineering

Lehman und Beladys (1980) Hypothesen

Software-Evolution Gesetz des fortgesetzten Wandels Gesetz der ansteigenden Komplexit¨at ... ⇒ st¨andige Anpassung erforderlich ⇒ Komplexit¨at muss kontrolliert und begrenzt werden

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

9/1

Einf¨ uhrung in das Software-Reengineering

Wunsch

¨ Gew¨ahlte L¨osung antizipiert m¨ ogliche Anderungen. ¨ Anderungen werden auf der ad¨aquaten Ebene vorgenommen. Dokumentation wird mitgef¨ uhrt.

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

10 / 1

Einf¨ uhrung in das Software-Reengineering

Wirklichkeit

Die Zukunft l¨asst sich nur begrenzt vorhersagen. Urspr¨ ungliche Systemstruktur wird ignoriert. Dokumentation ist unvollst¨andig oder obsolet. Mitarbeiter verlassen das Projekt (und mit ihnen verschwindet das ganze Wissen).

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

11 / 1

Einf¨ uhrung in das Software-Reengineering

Legacy System

Legacy: “A sum of money, or a specified article, given to another by will; anything handed down by an ancestor to a predecessor.” – Oxford English Dictionary

Definition Legacy System: Software-System, das geerbt wurde und einen Wert darstellt.

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

12 / 1

Einf¨ uhrung in das Software-Reengineering

Staged Software Life Cycle Model

Initial Development First running version

Evolution Changes Evolution Servicing Patches

Loss of evolvabilty Servicing Servicing discontinued

Phase−Out

Switch−off

Close−Down

– Rajlich und Bennett (2000)

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

13 / 1

Einf¨ uhrung in das Software-Reengineering

Versioned Staged Model (Rajlich und Bennett 2000) Initial Development First running version

Evolution Changes

Version 1 Servicing Patches Servicing Phase−Out Close−Down Evolution Changes Version 2 Servicing Patches Servicing Phase−Out Close−Down

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

14 / 1

Einf¨ uhrung in das Software-Reengineering

Begriffe

Software-Wartung

Renovation

Software-Evolution

Reclamation

Reengineering

Reverse Engineering

Software-Reengineering Business-ProcessReengineering

Rainer Koschke (Univ. Bremen)

Restrukturierung Wrapping

Vorlesung Software-Reengineering

WS 2007/2008

15 / 1

Einf¨ uhrung in das Software-Reengineering

Software-Wartung

ANSI/IEEE Standard 729-1983: “Modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a changed environment.” ¨ H¨aufiger Sprachgebrauch: Anderungen am System nach dessen Auslieferung. Schließt Anpassungen an neue Anforderungen ein. Besserer Begriff hierf¨ ur: Software-Evolution.

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

16 / 1

Einf¨ uhrung in das Software-Reengineering

Aufwand f¨ur Software-Wartung Corrective (fixing reported errors) 20% Perfective (new functionality) 55% Adaptive (new platforms or OS) 25 %

– Lientz und Swanson (1980) Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

2007-10-23

Vorlesung Software-Reengineering

WS 2007/2008

Corrective (fixing reported errors) 20%

Einf¨ uhrung

Perfective (new functionality)

Wartung Aufwand f¨ ur Software-Wartung

17 / 1

Aufwand f¨ur Software-Wartung

55% Adaptive (new platforms or OS) 25 %

– Lientz und Swanson (1980)

Lientz und Swanson (1980) haben den Aufwand f¨ ur verschiedene Wartungsarten anhand von 487 Software-Organisationen n¨ aher untersucht und festgestellt, dass ca. 80% der so genannten Wartung tats¨ achlich Erweiterungen sind (neue Funktionalit¨ at bzw. Anpassungen an neue Hardware- oder Software-Plattformen).

Einf¨ uhrung in das Software-Reengineering

Aufwand im Software-Lifecycle Verstehen 40% Spezifikation Entwickeln 20% 20% Test 40%

Entwurf 20% Kodierung 20% Ändern 40%

Boehm (1981) Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

Vorlesung Software-Reengineering

2007-10-23

Fjedstad und Hamlen (1979) WS 2007/2008

18 / 1

Aufwand im Software-Lifecycle Verstehen 40%

Einf¨ uhrung Wartung Aufwand im Software-Lifecycle

Spezifikation Entwickeln 20% 20% Test 40%

Entwurf 20% Kodierung 20% Ändern 40%

Boehm (1981)

Fjedstad und Hamlen (1979)

Eine typische Verteilung des Aufwands f¨ ur Aktivit¨ aten in der Erstentwicklung wurde von Boehm (1981) anhand groß angelegter empirischer Studien erhoben. Der Aufwand f¨ ur die Erstentwicklung ist jedoch vergleichsweise gering, wenn man ihn mit dem Aufwand f¨ ur Wartung vergleicht. Arthur (1988) hat insgesamt sechs Untersuchungen aus den Siebzigern zum Anteil der Wartung am Software-Lifecycle zusammen getragen. Der Aufwand liegt in diesen Untersuchungen zwischen 60 und 80 Prozent. Die Garnter Group, eine große Unternehmensberatung, sagt f¨ ur die Zukunft sogar einen ansteigenden Aufwand voraus, der bis zu 95% der Gesamtkosten f¨ ur Software einnehmen wird (Moad 1990). Fjedstad und Hamlen (1979) haben den Aufwand f¨ ur die einzelnen Wartungsaktivit¨ aten empirisch n¨ aher untersucht und dabei heraus gefunden, dass Wartungsprogrammierer ca. 50% ihrer Zeit allein mit der Analyse besch¨ aftigt sind, ¨ bevor sie eine Anderung tats¨ achlich vornehmen und testen k¨ onnen. Bei korrektiver Wartung (also Fehlerbeseitigung) liegt der Aufwand f¨ ur die Analyse gar bei 60%.

Einf¨ uhrung in das Software-Reengineering

Aufwand f¨ur Software-Evolution

US Air Force System (Boehm, 1975): $ 30 / Statement bei Erstentwicklung $ 4000 / Statement in der Wartung

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

19 / 1

Einf¨ uhrung in das Software-Reengineering

Jahr-2000-Problem

Beseitigung des Jahr-2000-Problems (gesch¨atzt von Cassell, 1997) 500.000.000.000 - 1.000.000.000.000 DM

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

20 / 1

Einf¨ uhrung in das Software-Reengineering

Reverse Engineering

License Restrictions: “Customer may not reverse engineer, disassemble, decompile, or translate the Software, or otherwise attempt to derive the source code of the Software.”

“To me the flow of time is irrelevant. You decide what you want. I then merely make sure that it has already happened.” – The Hitch Hiker’s Guide to the Galaxy

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

21 / 1

Einf¨ uhrung in das Software-Reengineering

Reverse Engineering (Chikofsky und Cross II. 1990) Identifikation der Systemkomponenten und deren Beziehungen, mit dem Ziel das System in einer anderen Form oder auf h¨ oherem Abstraktionsniveau zu beschreiben.

Forward Anforderungen Engineering

Rainer Koschke (Univ. Bremen)

Entwurf

Vorlesung Software-Reengineering

Code

WS 2007/2008

22 / 1

Einf¨ uhrung in das Software-Reengineering

Architekturrekonstruktion

Reverse Engineering mit dem Ziel, eine Beschreibung der Architektur des Systems zu erstellen. Anforderungen

Entwurf

Code

Architecture Reconstruction

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

23 / 1

Einf¨ uhrung in das Software-Reengineering

Restrukturierung (Chikofsky und Cross II. 1990)

Transformation einer Repr¨asentation in eine andere auf derselben ¨ Abstraktionsebene, ohne Anderung der Funktionalit¨at des Systems. Anforderungen

Entwurf

Code

Restrukturierung

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

24 / 1

Einf¨ uhrung in das Software-Reengineering

Reengineering (Chikofsky und Cross II. 1990) ¨ Untersuchung (Reverse Engineering) und Anderung des Systems, um es in neuer Form zu implementieren. Synonyme: Renovation, Reclamation. Forward Anforderungen Engineering

Entwurf

Code

Restrukturierung Reverse Engineering

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

25 / 1

Einf¨ uhrung in das Software-Reengineering

Reengineering-Varianten

Reines Reengineering: das System soll lediglich restrukturiert werden keine Funktionalit¨at kommt hinzu / wird ge¨andert Erweiterndes Reengineering: System wird zun¨achst analysiert und/oder restrukturiert, um dann Funktionalit¨at zu ¨andern oder hinzuzuf¨ ugen

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

26 / 1

Einf¨ uhrung in das Software-Reengineering

Wrapping

Das System erh¨alt eine neue Schnittstelle, bleibt aber ansonsten unangetastet. Interimsl¨osung, wenn System bald ausgewechselt werden soll. Notwendig, wenn das System Subsystem per Subsystem ge¨andert werden muss. Oft eingesetzt, um zeichenorientierte Anwendungen mit einer graphischen Benutzerschnittstelle zu versehen. Organisatorische Gr¨ unde: altes“ Wartungspersonal beh¨alt Kontrolle u ¨ber Wartung ihres“ ” ” Systems junges“ Wartungspersonal hat moderne“ Sicht ” ”

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

27 / 1

Einf¨ uhrung in das Software-Reengineering

Business Process Reengineering

“Business process reengineering is the search for, and the implementation of, radical change in business process to achieve breakthrough results.” – T.A. Stewart, Fortune Magazine’93.

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

28 / 1

Einf¨ uhrung in das Software-Reengineering

Business Process Reengineering

Etwas sachlicher: Wiedergewinnung der tats¨achlichen Abl¨aufe der Gesch¨aftsprozesse (Workflow) (z.B. Bestellungswesen, Auftragsabwicklung, etc.) ¨ Uberarbeitung und Neudefinition der Abl¨aufe

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

29 / 1

WS 2007/2008

30 / 1

Einf¨ uhrung in das Software-Reengineering

Ziele des Reverse Engineerings

Kontrolle der Komplexit¨at Gewinnung alternativer Sichten Wiedergewinnung verlorener Information Erkennung von Seiteneffekten Schaffung h¨oherer Abstraktionen Unterst¨ utzung von Wiederverwendung

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

Einf¨ uhrung in das Software-Reengineering

H¨aufige Reengineering-Aufgaben

Plattformanpassung ¨ Anderung der Programmiersprache neuer Standard, neue Sprache, neues Paradigma

Benutzerschnittstelle zeichenorientiert hin zu graphisch orientiert Mainframe hin zu Client-Server-Architektur Datenbankumstellung Pr¨aventive Maßnahmen, wie z.B. Verbesserung des Information Hidings, Remodularisierung, sind eher selten.

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

31 / 1

Einf¨ uhrung in das Software-Reengineering

Mass Changes

¨ Anderungen, die weite Teile des Codes bzw. sehr viele Systeme betreffen. Einf¨ uhrung des Euros Legacy to Internet Interoperability (Electronic Commerce) ¨ Anderung von Repr¨asentationsformen: Y2K Problem Erweiterung des Bar-Codes Unix-Datum

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

32 / 1

Einf¨ uhrung in das Software-Reengineering

Reengineering in der Praxis

Gegenw¨artig zur Verf¨ ugung stehende Werkzeuge: grep symbolische Debugger Cross-Reference-Tools (fertige Parser, die Basisinformationen extrahieren; z.T. mit Visualisierung durch Graphen) UML-CASE-Tools, die Klassendiagramme extrahieren programmierbare Analyse- und Transformationsumgebungen basierend auf abstrakten Syntaxb¨aumen (z.B. Refine von Reasoning Systems, DMS von Semantic Designs, RainCode)

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

33 / 1

Einf¨ uhrung in das Software-Reengineering

¨ Ubersicht u¨ber diese Vorlesung

Programmanalysen und -repr¨asentationen Refactoring und Transformationen Software-Produkt-Metriken Erkennung duplizierten Codes

Rainer Koschke (Univ. Bremen)

Begriffsanalyse Analyse und Restrukturierung von Vererbungshierarchien

Program-Slicing

Mustersuche

Software-Visualisierung

Merkmalsuche Software-Clustering, Architekturrekonstruktion und -validierung Reengineering-Projekte

Vorlesung Software-Reengineering

WS 2007/2008

34 / 1

Einf¨ uhrung in das Software-Reengineering

Software Engineering

“Software Engineering is reengineering on the empty system.” “Is it?” Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

35 / 1

Einf¨ uhrung in das Software-Reengineering

Unterschiede Forward Eng. / Reengineering Forward Engineering auf gr¨ uner Wiese Problem noch unklar Aussagen u ¨ber Aufwand, Dauer, Zuverl¨assigkeit etc. sind schwierig System existiert nicht Entwurf hat viele Freiheiten im sauberen Entwurf gibt es keine versteckten Abh¨angigkeiten

Rainer Koschke (Univ. Bremen)

Reengineering Problem weitgehend klar Idealerweise: Daten aus der Vergangenheit existieren, die Grundlage f¨ ur Sch¨atzungen darstellen System existiert Genaue Struktur/Qualit¨at bekannt? L¨ osung ist durch existierendes System beschr¨ankt ¨ Anderungen k¨ onnen globale Auswirkungen haben (viele versteckte Abh¨angigkeiten)

Vorlesung Software-Reengineering

WS 2007/2008

36 / 1

Einf¨ uhrung in das Software-Reengineering

Software Engineering & Reengineering

Reengineering beginnt oft bereits w¨ahrend der Erstentwicklung: neue Anforderungen treffen ein Missverst¨andnisse und Unklarheiten werden sichtbar der Entwurf hat sich als unzureichend erwiesen Integration anderer Komponenten macht Umstrukturierungen notwendig

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

37 / 1

Einf¨ uhrung in das Software-Reengineering

Weiterf¨uhrende Literatur

Chikofsky und Cross II. (1990): “Reverse Engineering and Design Recovery: A Taxonomy”, IEEE Software definiert Terminologie; ist die begriffliche Grundlage Baum¨ol u. a. (1996): “Einordnung und Terminologie des Reengineering” f¨ uhrt z.T. deutsche Begriffe ein

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

38 / 1

Einf¨ uhrung in das Software-Reengineering

B¨ucher I Demeyer u. a. (2002) stellen eine Reihe von Vorgehensweisen bei typischen Problemen des Reengineerings vor M¨ uller (1997) bietet eine Einf¨ uhrung in verschiedene Aspekte des Reengineerings (Programmverstehen, Metriken, Sprachkonversion, Restrukturierung, Wiederverwendung, Migration zu objektorientierten Systemen, Managementaspekte) obwohl meine Vorlesung 1999 in v¨ olliger Unkenntnis dieses Buches ¨ entstanden ist, ist doch eine große Uberlappung der Inhalte festzustellen (das Buch beschreibt aber weniger die konkreten Techniken)

Fowler (2000) beschreibt so genannte Bad Smells (Code-Anomalien) und zugeh¨orige Refactorings, um sie zu beseitigen Seacord u. a. (2003) beschreiben Methoden zur Modernisierung von Anwendungssystemen; in erster Linie Prozess- und Managementfragen werden erl¨autert Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

39 / 1

Einf¨ uhrung in das Software-Reengineering

B¨ucher II Simon u. a. (2006) beschreiben, wie man die Wartbarkeit von Systemen messen kann; das Ergebnis ist eine Einstufung in Analogie zu CMMI jedoch f¨ ur die innere Produktqualit¨at Sneed u. a. (2005) beschreiben organisatorische Aspekte und verschiedene Prozesse f¨ ur die Wartung und Weiterentwicklung von Software Masak (2006) diskutiert verschiedene Aspekte der Wartung und Evolution, insbesondere Beobachtungen, Metriken, Anti-Patterns und Management Pigoski (1996) behandelt Probleme und Managementl¨ osungen der Software-Wartung Lehner (1989) beschreibt Probleme und Managementl¨ osungen der Software-Wartung

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

40 / 1

Einf¨ uhrung in das Software-Reengineering

1 Arthur 1988 Arthur, L.J.: Software Evolution: The Software Maintenance Challenge. New York, NY : John Wiley & Sons, 1988 ¨ l, Ulrike ; Borchers, Jens ; Eicker, 2 Baum¨ ol u. a. 1996 Baumo Stefan ; Hildebrand, Knut ; Jung, Reinhard ; Lehner, Franz: Einordnung und Terminologie des Software Reengineering. In: Informatik Spektrum 19 (1996), S. 191–195 3 Boehm 1981 Boehm, Barry: Software Engineering Economics. Englewood Cliffs, NJ : Prentice Hall, 1981 4 Chikofsky und Cross II. 1990 Chikofsky, Elliot J. ; Cross II., James H.: Reverse Engineering and Design Recovery: A Taxonomy. In: IEEE Software 7 (1990), Januar, Nr. 1, S. 13–17 5 Demeyer u. a. 2002 Demeyer, Serge ; Ducasse, Stephane ; Nierstrasz, Oscar: Object Oriented Reengineering Patterns. Morgan Kaufmann, 2002 6 Fjedstad und Hamlen 1979 Fjedstad, R.K. ; Hamlen, W.T.: Application Program Maintenance Study: Report to our Respondents. In: Proceedings of the GUIDE 48. Philadelphia, PA, 1979 Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

41 / 1

Einf¨ uhrung in das Software-Reengineering

7 Fowler 2000 Fowler, Martin: Refactoring: Improving the Design of Existing Code. Addison-Wesley, 2000 8 Lehman 1980 Lehman, Meir M.: Programs, Life Cycles and Laws of Program Evolution. In: Proceedings of the IEEE, Special Issue on Software Evolution 68 (1980), September, Nr. 9, S. 1060–1076 9 Lehner 1989 Lehner, Franz: Nutzung und Wartung von Software. Carl Hanser Verlag, 1989 10 Lientz und Swanson 1980 Lientz, B.P. ; Swanson, E.B.: Software Maintenance Management. Reading, MA : Addison-Wesley, 1980 11 Masak 2006

Masak, Dieter: Legacysoftware. Springer, 2006

12 Moad 1990 Moad, J.: Maintaining the Competitive Edge. In: DATAMATION, 1990, S. 61–66 ¨ller, Bernd: Reengineering – Eine Einf¨ 13 M¨ uller 1997 Mu uhrung. B.G. Teubner, 1997

14 Pigoski 1996 Pigoski, Thomas M.: Practical Software Maintenance: Best Practices for Managing Your Software Inve John Wiley & Sons, Inc., 1996 Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

42 / 1

Einf¨ uhrung in das Software-Reengineering

15 Rajlich und Bennett 2000 Rajlich, Vaclav T. ; Bennett, Keith H.: A Staged Model for the Software Life Cycle. In: IEEE Computer 33 (2000), Nr. 7, S. 66–71 16 Seacord u. a. 2003 Seacord, Robert C. ; Plakosh, Daniel ; Lewis, Grace A.: Modernizing Legacy Systems. Addison-Wesley, 2003 17 Simon u. a. 2006 Simon, Frank ; Seng, Olaf ; Mohnhaupt, Thomas: Code-Quality-Management – Technische Qualit¨at industrieller Softwaresysteme transparent und vergleichbar gemacht. dpunkt.verlag, 2006 18 Sneed u. a. 2005 Sneed, Harry M. ; Hasitschka, Martin ; Teichmann, Maria-Therese: Software-Produktmanagement – Wartung und Weiterentwicklung bestehender Anwendungssysteme. dpunkt.verlag, 2005

Rainer Koschke (Univ. Bremen)

Vorlesung Software-Reengineering

WS 2007/2008

43 / 1