Vorlesung Software-Reengineering Prof. Dr. Rainer Koschke Arbeitsgruppe Softwaretechnik Fachbereich Mathematik und Informatik Universität Bremen Wintersemester 2011/12 Überblick I Einführung
Einführung in das Software-Reengineering: 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 Einführung in das Software-Reengineering: Administrativa Organisatorisches Vorlesung: montags, 10:30 12:00 Uhr, MZH 1470 und donnerstags, 14:00 15:30 Uhr, SFG 1040 Erreichbar: TAB 2.57, Telefon 218-9671, 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/ Literatur: Folien zur Vorlesung und verwendete Artikel http://www.informatik.uni-bremen.de/st/ lehredetails.php?id=&lehre_id=310 Reengineering-Bibliographie: http: //www.iste.uni-stuttgart.de/ps/reengineering/
Einführung in das Software-Reengineering: Administrativa Scheinbedingungen Modulprüfung: 30 min mündliche Prüfung ansonsten 1 erfolgreiche Bearbeitung von praktischen Aufgaben (1-2 Personen): Erweiterung von 1 syntaktischer Analyse und AST-Generierung 2 semantische Analyse 3 Metrikberechnung mittels Visitor-Pattern für AST 4 Implementierung zweier Refactorings 5 Architekturextraktion 2 Fachgespräch (einzeln, benotet; zählt zu einem Drittel) Einführung in das Software-Reengineering: Lernziele Wegweiser Was versteht man unter Reengineering genau? Welche Gebiete des Reengineerings gibt es? Was ist der Unterschied zur klassischen Vorwärtsentwicklung?
Einführung in das Software-Reengineering: Motivation 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 Einführung in das Software-Reengineering: Motivation Wunsch Gewählte Lösung antizipiert mögliche Änderungen. Änderungen werden auf der adäquaten Ebene vorgenommen. Dokumentation wird mitgeführt.
Einführung in das Software-Reengineering: Motivation 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). Einführung in das Software-Reengineering: Motivation 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.
Einführung in das Software-Reengineering: Motivation 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) Einführung in das Software-Reengineering: Motivation 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
Einführung in das Software-Reengineering: Wichtige Begriffe Begriffe Software-Wartung Software-Evolution Reengineering Software-Reengineering Business-Process- Reengineering Renovation Reclamation Refactoring Reverse Engineering Restrukturierung Wrapping Einführung in das Software-Reengineering: Wartung 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.
Einführung in das Software-Reengineering: Wartung Aufwand für Software-Wartung korrektiv 22% 12% perfektiv adaptiv 25 % 41% erweiternd Lientz und Swanson (1980) 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).
Einführung in das Software-Reengineering: Wartung Aufwand im Software-Lifecycle Verstehen 40% Spezifikation 20% Entwickeln 20% Test 40% Entwurf 20% Kodierung 20% Ändern 40% Boehm (1981) Fjeldstad und Hamlen (1979) 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%.
Einführung in das Software-Reengineering: Wartung Aufwand für Software-Evolution US Air Force System (Boehm, 1975): $ 30 / Statement bei Erstentwicklung $ 4000 / Statement in der Wartung Einführung in das Software-Reengineering: Wartung Jahr-2000-Problem Beseitigung des Jahr-2000-Problems (geschätzt von Cassell, 1997) 500.000.000.000-1.000.000.000.000 DM
Einführung in das Software-Reengineering: Reverse Engineering 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 Einführung in das Software-Reengineering: Reverse Engineering 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
Einführung in das Software-Reengineering: Reverse Engineering Architekturrekonstruktion Definition Architekturrekonstruktion: Reverse Engineering mit dem Ziel, eine Beschreibung der Architektur des Systems zu erstellen. Anforderungen Entwurf Code Architecture Reconstruction Einführung in das Software-Reengineering: Restrukturierung 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
Einführung in das Software-Reengineering: Reengineering 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 Einführung in das Software-Reengineering: Reengineering 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
Einführung in das Software-Reengineering: Wrapping 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 Einführung in das Software-Reengineering: Business Process 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.
Einführung in das Software-Reengineering: Business Process Reengineering 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 Einführung in das Software-Reengineering: Ziele und Aufgaben 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
Einführung in das Software-Reengineering: Ziele und Aufgaben 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. Einführung in das Software-Reengineering: Ziele und Aufgaben 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
Einführung in das Software-Reengineering: Ziele und Aufgaben 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) Einführung in das Software-Reengineering: Ziele und Aufgaben Ü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
Einführung in das Software-Reengineering: Unterschiede zur Vorwärtsentwicklung Software Engineering Software engineering is reengineering on the empty system. Is it? Einführung in das Software-Reengineering: Unterschiede zur Vorwärtsentwicklung 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)
Einführung in das Software-Reengineering: Unterschiede zur Vorwärtsentwicklung 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 Einführung in das Software-Reengineering: Unterschiede zur Vorwärtsentwicklung 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
Einführung in das Software-Reengineering: Unterschiede zur Vorwärtsentwicklung 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 Einführung in das Software-Reengineering: Unterschiede zur Vorwärtsentwicklung 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
Einführung in das Software-Reengineering: Unterschiede zur Vorwärtsentwicklung 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 Einführung in das Software-Reengineering: Unterschiede zur Vorwärtsentwicklung 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. Springer, 2006 12 Moad 1990 Moad, J.: Maintaining the Competitive Edge. In: DATAMATION, 1990, S. 61 66
Einführung in das Software-Reengineering: Unterschiede zur Vorwärtsentwicklung 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 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 Einführung in das Software-Reengineering: Unterschiede zur Vorwärtsentwicklung 18 Sneed u. a. 2005 Sneed, Harry M. ; Hasitschka, Martin ; Teichmann, Maria-Therese: Software-Produktmanagement Wartung und Weiterentwicklung bestehender Anwendungssysteme. dpunkt.verlag, 2005