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