Vorlesung Software-Reengineering Prof. Dr. Rainer Koschke Arbeitsgruppe Softwaretechnik Fachbereich Mathematik und Informatik Universität Bremen Wintersemester 2013/14 Überblick I Einführung
Einführung in das Software-Reengineering I Einführung Administrativa Lernziele Motivation Wichtige Begriffe Wartung Reverse Engineering Restrukturierung Reengineering Wrapping Business Process Reengineering Ziele und Aufgaben Unterschiede zur Vorwärtsentwicklung 3 / 46 Organisatorisches Vorlesung: montags, 10:30 12:00 Uhr, MZH 1450 donnerstags, 14:00 s.t. 15:30 Uhr, MZH 1450 Erreichbar: TAB 2.57, Telefon 218-64481, koschke@tzi.de Sprechstunde nach Vereinbarung Video im Netz http://mlecture.uni-bremen.de bitte bei Stud.IP anmelden unter https://elearning.uni-bremen.de/ Buch zur Vorlesung bei Stud.IP Literatur: Folien zur Vorlesung und verwendete Artikel http://www.informatik.uni-bremen.de/st/ lehredetails.php?id=&lehre_id=313 4 / 46
Scheinbedingungen Modulprüfung: 30 min mündliche Prüfung ansonsten 1 erfolgreiche Bearbeitung von praktischen Aufgaben (1-2 Personen): Eclipse-Plugins für 1 Abhängigkeitsanalyse 2 Metrikberechnung 3 Implementierung zweier Refactorings 2 Fachgespräch (einzeln, benotet; zählt zu einem Drittel) 5 / 46 Übersicht über diese Vorlesung Statische Programmanalysen und -repräsentationen Dynamische Analysen Program-Slicing Refactoring und Transformationen Software-Produkt- Metriken Erkennung duplizierten Codes und anderer Bad Smells Software-Visualisierung Analyse und Restrukturierung von Vererbungshierarchien Merkmalsuche (Feature-Location) Software-Clustering, Architekturrekonstruktion und -validierung Reengineering-Projekte 6 / 46
Wegweiser Was versteht man unter Reengineering genau? Welche Gebiete des Reengineerings gibt es? Was ist der Unterschied zur klassischen Vorwärtsentwicklung? 7 / 46 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 10 / 46
Wunsch Gewählte Lösung antizipiert mögliche Änderungen. Änderungen werden auf der adäquaten Ebene vorgenommen. Dokumentation wird mitgeführt. 11 / 46 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). 12 / 46
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. 13 / 46 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) 14 / 46
Versioned Staged Model (Rajlich und Bennett 2000) First running version Initial Development Version 1 Evolution Changes Servicing Servicing Patches Phase Out Version 2 Close Down Evolution Changes Servicing Patches Servicing Phase Out Close Down 15 / 46 Begriffe Software-Wartung Software-Evolution Reengineering Software-Reengineering Business-Process- Reengineering Renovation Reclamation Refactoring Reverse Engineering Restrukturierung Wrapping 17 / 46
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äufiger Sprachgebrauch: Änderungen am System nach dessen Auslieferung. Schließt Anpassungen an neue Anforderungen ein. Besserer Begriff hierfür: Software-Evolution. 18 / 46 Aufwand für Software-Wartung korrektiv 22% 12% perfektiv adaptiv 25 % 41% erweiternd Lientz und Swanson (1980) 19 / 46
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). Aufwand im Software-Lifecycle Verstehen 40% Spezifikation 20% Entwickeln 20% Test 40% Entwurf 20% Kodierung 20% Ändern 40% Boehm (1981) Fjeldstad und Hamlen (1979) 20 / 46
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%. Aufwand für Software-Evolution US Air Force System (Boehm, 1975): $ 30 / Statement bei Erstentwicklung $ 4000 / Statement in der Wartung 21 / 46
Jahr-2000-Problem Beseitigung des Jahr-2000-Problems (geschätzt von Cassell, 1997) 500.000.000.000-1.000.000.000.000 DM 22 / 46 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 23 / 46
Reverse Engineering (Chikofsky und Cross II. 1990) Definition Reverse Engineering: 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 Reverse Engineering 25 / 46 Architekturrekonstruktion Definition Architekturrekonstruktion: Reverse Engineering mit dem Ziel, eine Beschreibung der Architektur des Systems zu erstellen. Anforderungen Entwurf Code Architecture Reconstruction 26 / 46
Restrukturierung (Chikofsky und Cross II. 1990) Definition Restrukturierung: Transformation einer Repräsentation in eine andere auf derselben Abstraktionsebene, ohne Änderung der Funktionalität des Systems. Anforderungen Entwurf Code Restrukturierung 27 / 46 Reengineering (Chikofsky und Cross II. 1990) Definition Reengineering: 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 28 / 46
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 29 / 46 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 30 / 46
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. 31 / 46 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 32 / 46
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 33 / 46 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. 34 / 46
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 35 / 46 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) 36 / 46
Software Engineering Software engineering is reengineering on the empty system. Is it? 37 / 46 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) 38 / 46
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 39 / 46 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 40 / 46
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 41 / 46 Bücher II Seacord u. a. (2003) beschreiben Methoden zur Modernisierung von Anwendungssystemen; in erster Linie Prozess- und Managementfragen werden erläutert 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 42 / 46
1 Arthur 1988 Arthur, L.J.: Software Evolution: The Software Maintenance Challenge. New York, NY : John Wiley & Sons, 1988 2 Baumöl u. a. 1996 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. 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 43 / 46 6 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 : The Guide Corporation, 1979 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: Das lange Leben der Altsysteme. Springer, 2006 44 / 46
12 Moad 1990 Moad, J.: Maintaining the Competitive Edge. In: DATAMATION, 1990, S. 61 66 13 Müller 1997 Müller, Bernd: Reengineering Eine Einführung. B.G. Teubner, 1997 14 Pigoski 1996 Pigoski, Thomas M.: Practical Software Maintenance: Best Practices for Managing Your Software Investment. John Wiley & Sons, Inc., 1996 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ät industrieller Softwaresysteme transparent und vergleichbar gemacht. dpunkt.verlag, 2006 45 / 46 18 Sneed u. a. 2005 Sneed, Harry M. ; Hasitschka, Martin ; Teichmann, Maria-Therese: Software-Produktmanagement Wartung und Weiterentwicklung bestehender Anwendungssysteme. dpunkt.verlag, 2005 46 / 46