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 Einführung

3 Einführung in das Software-Reengineering 1 Einführung Administrativa Lernziele Motivation Wichtige Begriffe Wartung Reverse Engineering Restrukturierung Reengineering Wrapping Business Process Reengineering Ziele und Aufgaben Unterschiede zur Vorwärtsentwicklung Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

4 Organisatorisches Vorlesung: montags, 10:15-11:45 Uhr, Raum MZH 7260 Vorlesung/Übung (alternierend): donnerstags, 8:30-10:00 Uhr, Raum MZH 5210 Erreichbar: TAB 2.57, Telefon , Sprechstunde nach Vereinbarung Video im Netz bitte bei Stud.IP anmelden unter Literatur: Folien zur Vorlesung und verwendete Artikel php?id=&lehre_id=309 Reengineering-Bibliographie: Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

5 Scheinbedingungen Modulprüfung: 30 min mündliche Prüfung ansonsten 1 erfolgreiche Bearbeitung von praktischen Aufgaben (1-2 Personen): 1 Qualitätsanalyse (quellcodenah) 2 Refactoring/Transformation 3 Architekturprüfung 2 Fachgespräch (einzeln, benotet; zählt zu einem Drittel) Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

6 Wegweiser Was versteht man unter Reengineering genau? Welche Gebiete des Reengineerings gibt es? Was ist der Unterschied zur klassischen Vorwärtsentwicklung? Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

7 Lehman und Beladys (1980) Hypothesen Software-Evolution Gesetz des fortgesetzten Wandels Gesetz der ansteigenden Komplexität... ständige Anpassung erforderlich Komplexität muss kontrolliert und begrenzt werden Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

8 Wunsch Gewählte Lösung antizipiert mögliche Änderungen. Änderungen werden auf der adäquaten Ebene vorgenommen. Dokumentation wird mitgeführt. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

9 Wirklichkeit Die Zukunft lässt sich nur begrenzt vorhersagen. Ursprüngliche Systemstruktur wird ignoriert. Dokumentation ist unvollständig oder obsolet. Mitarbeiter verlassen das Projekt (und mit ihnen verschwindet das ganze Wissen). Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

10 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 2009/ / 43

11 Staged Software Life Cycle Model Initial Development First running version Loss of evolvabilty Evolution Servicing Evolution Changes Servicing Patches Servicing discontinued Switch off Phase Out Close Down Rajlich und Bennett (2000) Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

12 Versioned Staged Model (Rajlich und Bennett 2000) Initial Development First running version Evolution Changes Version 1 Servicing Patches Servicing Phase Out Version 2 Close Down Evolution Changes Servicing Patches Servicing Phase Out Close Down Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

13 Begriffe Software-Wartung Software-Evolution Reengineering Software-Reengineering Business-Process- Reengineering Renovation Reclamation Reverse Engineering Restrukturierung Wrapping Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

14 Software-Wartung ANSI/IEEE Standard : 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äufiger Sprachgebrauch: Änderungen am System nach dessen Auslieferung. Schließt Anpassungen an neue Anforderungen ein. Besserer Begriff hierfür: Software-Evolution. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

15 Aufwand für Software-Wartung Lientz und Swanson (1980) Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43 korrektiv 22% 12% perfektiv adaptiv 25 % 41% erweiternd

16 Lientz und Swanson (1980) haben den Aufwand für verschiedene Wartungsarten anhand von 487 Software-Organisationen näher untersucht und festgestellt, dass ca. 80% der so genannten Wartung tatsächlich Erweiterungen sind (neue Funktionalität bzw. Anpassungen an neue Hardware- oder Software-Plattformen).

17 Aufwand im Software-Lifecycle Verstehen 40% Spezifikation 20% Entwickeln 20% Test 40% Entwurf 20% Kodierung 20% Ändern 40% Boehm (1981) Fjeldstad und Hamlen (1979) Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

18 Eine typische Verteilung des Aufwands für Aktivitäten in der Erstentwicklung wurde von Boehm (1981) anhand groß angelegter empirischer Studien erhoben. Der Aufwand für die Erstentwicklung ist jedoch vergleichsweise gering, wenn man ihn mit dem Aufwand für 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ür die Zukunft sogar einen ansteigenden Aufwand voraus, der bis zu 95% der Gesamtkosten für Software einnehmen wird (Moad 1990). Fjeldstad und Hamlen (1979) haben den Aufwand für die einzelnen Wartungsaktivitäten empirisch näher untersucht und dabei heraus gefunden, dass Wartungsprogrammierer ca. 50% ihrer Zeit allein mit der Analyse beschäftigt sind, bevor sie eine Änderung tatsächlich vornehmen und testen können. Bei korrektiver Wartung (also Fehlerbeseitigung) liegt der Aufwand für die Analyse gar bei 60%.

19 Aufwand für 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 2009/ / 43

20 Jahr-2000-Problem Beseitigung des Jahr-2000-Problems (geschätzt von Cassell, 1997) DM Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

21 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 2009/ / 43

22 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öherem Abstraktionsniveau zu beschreiben. Forward Engineering Anforderungen Entwurf Code Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

23 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 2009/ / 43

24 Restrukturierung (Chikofsky und Cross II. 1990) Transformation einer Repräsentation in eine andere auf derselben Abstraktionsebene, ohne Änderung der Funktionalität des Systems. Anforderungen Entwurf Code Restrukturierung Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

25 Reengineering (Chikofsky und Cross II. 1990) Untersuchung (Reverse Engineering) und Änderung des Systems, um es in neuer Form zu implementieren. Synonyme: Renovation, Reclamation. Forward Engineering Anforderungen Entwurf Code Restrukturierung Reverse Engineering Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

26 Reengineering-Varianten Reines Reengineering: das System soll lediglich restrukturiert werden keine Funktionalität kommt hinzu / wird geändert Erweiterndes Reengineering: System wird zunächst analysiert und/oder restrukturiert, um dann Funktionalität zu ändern oder hinzuzufügen Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

27 Wrapping Das System erhält eine neue Schnittstelle, bleibt aber ansonsten unangetastet. Interimslösung, wenn System bald ausgewechselt werden soll. Notwendig, wenn das System Subsystem per Subsystem geändert werden muss. Oft eingesetzt, um zeichenorientierte Anwendungen mit einer graphischen Benutzerschnittstelle zu versehen. Organisatorische Gründe: altes Wartungspersonal behält Kontrolle über Wartung ihres Systems junges Wartungspersonal hat moderne Sicht Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

28 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 2009/ / 43

29 Business Process Reengineering Etwas sachlicher: Wiedergewinnung der tatsächlichen Abläufe der Geschäftsprozesse (Workflow) (z.b. Bestellungswesen, Auftragsabwicklung etc.) Überarbeitung und Neudefinition der Abläufe Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

30 Ziele des Reverse Engineerings Kontrolle der Komplexität Gewinnung alternativer Sichten Wiedergewinnung verlorener Information Erkennung von Seiteneffekten Schaffung höherer Abstraktionen Unterstützung von Wiederverwendung Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

31 Häufige Reengineering-Aufgaben Plattformanpassung Änderung der Programmiersprache neuer Standard, neue Sprache, neues Paradigma Benutzerschnittstelle zeichenorientiert hin zu graphisch orientiert Mainframe hin zu Client-Server-Architektur Datenbankumstellung Präventive Maßnahmen, wie z.b. Verbesserung des Information Hidings oder Remodularisierung, sind eher selten. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

32 Mass Changes Änderungen, die weite Teile des Codes bzw. sehr viele Systeme betreffen. Einführung des Euros Legacy to Internet Interoperability (Electronic Commerce) Änderung von Repräsentationsformen: Y2K Problem Erweiterung des Bar-Codes Unix-Datum Wunsch nach hohem Automatisierungsgrad Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

33 Reengineering in der Praxis Gegenwärtig zur Verfügung 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äumen (z.b. Refine von Reasoning Systems, DMS von Semantic Designs, RainCode) Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

34 Übersicht über diese Vorlesung Statische Programmanalysen und -repräsentationen Dynamische Analysen Program-Slicing Refactoring und Transformationen Software-Produkt-Metriken Erkennung duplizierten Codes Mustersuche Software-Visualisierung Begriffsanalyse Analyse und Restrukturierung von Vererbungshierarchien Merkmalsuche Software-Clustering, Architekturrekonstruktion und -validierung Reengineering-Projekte Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

35 Software Engineering Software engineering is reengineering on the empty system. Is it? Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

36 Unterschiede Forward Eng. / Reengineering Forward Engineering auf grüner Wiese Problem noch unklar Aussagen über Aufwand, Dauer, Zuverlässigkeit etc. sind schwierig System existiert nicht Entwurf hat viele Freiheiten im sauberen Entwurf gibt es keine versteckten Abhängigkeiten Reengineering Problem weitgehend klar Idealerweise: Daten aus der Vergangenheit existieren, die Grundlage für Schätzungen darstellen System existiert Genaue Struktur/Qualität bekannt? Lösung ist durch existierendes System beschränkt Änderungen können globale Auswirkungen haben (viele versteckte Abhängigkeiten) Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

37 Software Engineering & Reengineering Reengineering beginnt oft bereits während der Erstentwicklung: neue Anforderungen treffen ein Missverständnisse 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 2009/ / 43

38 Weiterführende Literatur Chikofsky und Cross II. (1990): Reverse Engineering and Design Recovery: A Taxonomy, IEEE Software definiert Terminologie; ist die begriffliche Grundlage Baumöl u. a. (1996): Einordnung und Terminologie des Reengineering führt z.t. deutsche Begriffe ein Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

39 Bücher I Demeyer u. a. (2002) stellen eine Reihe von Vorgehensweisen bei typischen Problemen des Reengineerings vor Müller (1997) bietet eine Einführung in verschiedene Aspekte des Reengineerings (Programmverstehen, Metriken, Sprachkonversion, Restrukturierung, Wiederverwendung, Migration zu objektorientierten Systemen, Managementaspekte) obwohl meine Vorlesung 1999 in völliger Unkenntnis dieses Buches entstanden ist, ist doch eine große Überlappung der Inhalte festzustellen (das Buch beschreibt aber weniger die konkreten Techniken) Fowler (2000) beschreibt so genannte Bad Smells (Code-Anomalien) und zugehörige Refactorings, um sie zu beseitigen Seacord u. a. (2003) beschreiben Methoden zur Modernisierung von Anwendungssystemen; in erster Linie Prozess- und Managementfragen werden erläutert Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

40 Bücher 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ür die innere Produktqualität Sneed u. a. (2005) beschreiben organisatorische Aspekte und verschiedene Prozesse für 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ösungen der Software-Wartung Lehner (1989) beschreibt Probleme und Managementlösungen der Software-Wartung Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

41 Arthur 1988 Arthur, L.J.: Software Evolution: The Software Maintenance Challenge. New York, NY : John Wiley & Sons, 1988 Baumöl u. a Baumöl, Ulrike ; Borchers, Jens ; Eicker, Stefan ; Hildebrand, Knut ; Jung, Reinhard ; Lehner, Franz: Einordnung und Terminologie des Software Reengineering. In: Informatik Spektrum 19 (1996), S Boehm 1981 Boehm, Barry: Software Engineering Economics. Englewood Cliffs, NJ : Prentice Hall, 1981 Chikofsky und Cross II Chikofsky, Elliot J. ; Cross II., James H.: Reverse Engineering and Design Recovery: A Taxonomy. In: IEEE Software 7 (1990), Januar, Nr. 1, S Demeyer u. a Demeyer, Serge ; Ducasse, Stephane ; Nierstrasz, Oscar: Object Oriented Reengineering Patterns. Morgan Kaufmann, 2002 Fjeldstad und Hamlen 1979 Fjeldstad, 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 2009/ / 43

42 Fowler 2000 Fowler, Martin: Refactoring: Improving the Design of Existing Code. Addison-Wesley, 2000 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 Lehner 1989 Lehner, Franz: Nutzung und Wartung von Software. Carl Hanser Verlag, 1989 Lientz und Swanson 1980 Lientz, B.P. ; Swanson, E.B.: Software Maintenance Management. Reading, MA : Addison-Wesley, 1980 Masak 2006 Masak, Dieter: Legacysoftware. Springer, 2006 Moad 1990 Moad, J.: Maintaining the Competitive Edge. In: DATAMATION, 1990, S Müller 1997 Müller, Bernd: Reengineering Eine Einführung. B.G. Teubner, 1997 Pigoski 1996 Pigoski, Thomas M.: Practical Software Maintenance: Best Practices for Managing Your Softwar John Wiley & Sons, Inc., 1996 Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/ / 43

43 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 Seacord u. a Seacord, Robert C. ; Plakosh, Daniel ; Lewis, Grace A.: Modernizing Legacy Systems. Addison-Wesley, 2003 Simon u. a Simon, Frank ; Seng, Olaf ; Mohnhaupt, Thomas: Code-Quality-Management Technische Qualität industrieller Softwaresysteme transparent und vergleichbar gemacht. dpunkt.verlag, 2006 Sneed u. a 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 2009/ / 43