Vorlesung Software-Reengineering
Prof. Dr. Rainer Koschke
Arbeitsgruppe SoftwaretechnikFachbereich Mathematik und Informatik
Universitat Bremen
Wintersemester 2010/11
Uberblick IEinfuhrung
Einfuhrung in das Software-Reengineering:
Einfuhrung in das Software-Reengineering I
EinfuhrungAdministrativaLernzieleMotivationWichtige BegriffeWartungReverse EngineeringRestrukturierungReengineeringWrappingBusiness Process ReengineeringZiele und AufgabenUnterschiede zur Vorwartsentwicklung
Einfuhrung in das Software-Reengineering: Administrativa
Organisatorisches
Vorlesung: montags, 10:15 - 11:45 Uhr, MZH Senatssaal(1400), und donnerstags, 8:30 - 10:00 Uhr, SFG 1040
Vorlesung/Ubung alternierend alle zwei Wochen
Erreichbar: TAB 2.57, Telefon 218-9671, [email protected]
Sprechstunde nach Vereinbarung
Video im Netz http://mlecture.uni-bremen.de
bitte bei Stud.IP anmelden unterhttps://elearning.uni-bremen.de/
Literatur: Folien zur Vorlesung und verwendete Artikelhttp://www.informatik.uni-bremen.de/st/
lehredetails.php?id=&lehre_id=310
Reengineering-Bibliographie:http:
//www.iste.uni-stuttgart.de/ps/reengineering/
Einfuhrung in das Software-Reengineering: Administrativa
Scheinbedingungen
Modulprufung: 30 min mundliche Prufungansonsten
1 erfolgreiche Bearbeitung von praktischen Aufgaben (1-2Personen): Erweiterung von
1 syntaktischer Analyse und AST-Generierung2 semantische Analyse3 Metrikberechnung mittels Visitor-Pattern fur AST4 Implementierung der Refactorings Rename und Encapsulate
Field5 Architekturextraktion
2 Fachgesprach (einzeln, benotet; zahlt zu einem Drittel)
Einfuhrung in das Software-Reengineering: Lernziele
Wegweiser
Was versteht man unter Reengineering genau?
Welche Gebiete des Reengineerings gibt es?
Was ist der Unterschied zur klassischenVorwartsentwicklung?
Einfuhrung in das Software-Reengineering: Motivation
Lehman und Beladys (1980) Hypothesen
Software-Evolution
Gesetz des fortgesetzten Wandels
Gesetz der ansteigenden Komplexitat
. . .
⇒ standige Anpassung erforderlich
⇒ Komplexitat muss kontrolliert und begrenzt werden
Einfuhrung in das Software-Reengineering: Motivation
Wunsch
Gewahlte Losung antizipiert mogliche Anderungen.
Anderungen werden auf der adaquaten Ebene vorgenommen.
Dokumentation wird mitgefuhrt.
Einfuhrung in das Software-Reengineering: Motivation
Wirklichkeit
Die Zukunft lasst sich nur begrenzt vorhersagen.
Ursprungliche Systemstruktur wird ignoriert.
Dokumentation ist unvollstandig oder obsolet.
Mitarbeiter verlassen das Projekt (und mit ihnen verschwindetdas ganze Wissen).
Einfuhrung in das Software-Reengineering: Motivation
Legacy System
Legacy:
“A sum of money, or a specified article, given to anotherby will; anything handed down by an ancestor to apredecessor.”
– Oxford English Dictionary
DefinitionLegacy System: Software-System, das geerbt wurde und einenWert darstellt.
Einfuhrung in das Software-Reengineering: Motivation
Staged Software Life Cycle Model
Evolution
Servicing
Phase−Out
Close−Down
Initial Development
Evolution ChangesFirst running version
Servicing PatchesLoss of evolvabilty
Servicing discontinued
Switch−off
– Rajlich und Bennett (2000)
Einfuhrung in das Software-Reengineering: Motivation
Versioned Staged Model (Rajlich und Bennett 2000)
Initial Development
Phase−Out
Close−Down
ServicingServicing Patches
Version 1
Evolution Changes
Phase−Out
Close−Down
ServicingServicing Patches
Version 2
Evolution Changes
First running version
Einfuhrung in das Software-Reengineering: Wichtige Begriffe
Begriffe
Software-Wartung
Software-Evolution
Reengineering
Software-Reengineering
Business-Process-Reengineering
Renovation
Reclamation
Refactoring
Reverse Engineering
Restrukturierung
Wrapping
Einfuhrung in das Software-Reengineering: Wartung
Software-Wartung
ANSI/IEEE Standard 729-1983:“Modification of a software product after delivery tocorrect faults, to improve performance or other attributes,or to adapt the product to a changed environment.”
Haufiger Sprachgebrauch: Anderungen am System nach dessenAuslieferung.Schließt Anpassungen an neue Anforderungen ein.Besserer Begriff hierfur: Software-Evolution.
Einfuhrung in das Software-Reengineering: Wartung
Aufwand fur Software-Wartung
22%
korrektiv
25 %adaptiv
perfektiv
12%
erweiternd41%
– Lientz und Swanson (1980)
Lientz und Swanson (1980) haben den Aufwand fur verschiedene Wartungsarten anhand von 487Software-Organisationen naher untersucht und festgestellt, dass ca. 80% der so genannten Wartung tatsachlichErweiterungen sind (neue Funktionalitat bzw. Anpassungen an neue Hardware- oder Software-Plattformen).
Einfuhrung in das Software-Reengineering: Wartung
Aufwand im Software-Lifecycle
Entwurf
20%
Test
40%
Spezifikation
20%
Kodierung
20%
Entwickeln 20%
Verstehen 40%
Ändern 40%
Boehm (1981) Fjeldstad und Hamlen (1979)
Eine typische Verteilung des Aufwands fur Aktivitaten in der Erstentwicklung wurde von Boehm (1981) anhand großangelegter empirischer Studien erhoben.Der Aufwand fur die Erstentwicklung ist jedoch vergleichsweise gering, wenn man ihn mit dem Aufwand fur Wartungvergleicht. Arthur (1988) hat insgesamt sechs Untersuchungen aus den Siebzigern zum Anteil der Wartung amSoftware-Lifecycle zusammen getragen. Der Aufwand liegt in diesen Untersuchungen zwischen 60 und 80 Prozent. DieGarnter Group, eine große Unternehmensberatung, sagt fur die Zukunft sogar einen ansteigenden Aufwand voraus, derbis zu 95% der Gesamtkosten fur Software einnehmen wird (Moad 1990).Fjeldstad und Hamlen (1979) haben den Aufwand fur die einzelnen Wartungsaktivitaten empirisch naher untersucht unddabei heraus gefunden, dass Wartungsprogrammierer ca. 50% ihrer Zeit allein mit der Analyse beschaftigt sind, bevor sieeine Anderung tatsachlich vornehmen und testen konnen. Bei korrektiver Wartung (also Fehlerbeseitigung) liegt derAufwand fur die Analyse gar bei 60%.
Einfuhrung in das Software-Reengineering: Wartung
Aufwand fur Software-Evolution
US Air Force System (Boehm, 1975):
$ 30 / Statement bei Erstentwicklung
$ 4000 / Statement in der Wartung
Einfuhrung in das Software-Reengineering: Wartung
Jahr-2000-Problem
Beseitigung des Jahr-2000-Problems (geschatzt von Cassell,1997) 500.000.000.000 - 1.000.000.000.000 DM
Einfuhrung in das Software-Reengineering: Reverse Engineering
Reverse Engineering
License Restrictions:“Customer may not reverse engineer, disassemble,decompile, or translate the Software, or otherwiseattempt to derive the source code of the Software.”
“To me the flow of time is irrelevant. You decide what youwant. I then merely make sure that it has alreadyhappened.”
– The Hitch Hiker’s Guide to the Galaxy
Einfuhrung in das Software-Reengineering: Reverse Engineering
Reverse Engineering (Chikofsky und Cross II. 1990)
DefinitionReverse Engineering: Identifikation der Systemkomponenten undderen Beziehungen mit dem Ziel, das System in einer anderenForm oder auf hoherem Abstraktionsniveau zu beschreiben.
Reverse
Engineering
Forward
Engineering
Anforderungen Entwurf Code
Einfuhrung in das Software-Reengineering: Reverse Engineering
Architekturrekonstruktion
DefinitionArchitekturrekonstruktion: Reverse Engineering mit dem Ziel,eine Beschreibung der Architektur des Systems zu erstellen.
Architecture
Reconstruction
Anforderungen Entwurf Code
Einfuhrung in das Software-Reengineering: Restrukturierung
Restrukturierung (Chikofsky und Cross II. 1990)
DefinitionRestrukturierung: Transformation einer Reprasentation in eineandere auf derselben Abstraktionsebene, ohne Anderung derFunktionalitat des Systems.
Restrukturierung
Anforderungen Entwurf Code
Einfuhrung in das Software-Reengineering: Reengineering
Reengineering (Chikofsky und Cross II. 1990)
DefinitionReengineering: Untersuchung (Reverse Engineering) undAnderung des Systems, um es in neuer Form zu implementieren.Synonyme: Renovation, Reclamation.
Restrukturierung
Reverse
Engineering
Forward
Engineering
Anforderungen Entwurf Code
Einfuhrung in das Software-Reengineering: Reengineering
Reengineering-Varianten
Reines Reengineering:
das System soll lediglich restrukturiert werden
keine Funktionalitat kommt hinzu / wird geandert
Erweiterndes Reengineering:
System wird zunachst analysiert und/oder restrukturiert, umdann Funktionalitat zu andern oder hinzuzufugen
Einfuhrung in das Software-Reengineering: Wrapping
Wrapping
Das System erhalt eine neue Schnittstelle, bleibt aber ansonstenunangetastet.
Interimslosung, wenn System bald ausgewechselt werdensoll.
Notwendig, wenn das System Subsystem per Subsystemgeandert werden muss.
Oft eingesetzt, um zeichenorientierte Anwendungen mit einergraphischen Benutzerschnittstelle zu versehen.Organisatorische Grunde:
”altes“ Wartungspersonal behalt Kontrolle uber Wartung ”ihres“Systems
”junges“ Wartungspersonal hat ”moderne“ Sicht
Einfuhrung in das Software-Reengineering: Business Process Reengineering
Business Process Reengineering
“Business process reengineering is the search for, andthe implementation of, radical change in businessprocess to achieve breakthrough results.”
– T.A. Stewart, Fortune Magazine’93.
Einfuhrung in das Software-Reengineering: Business Process Reengineering
Business Process Reengineering
Etwas sachlicher:
Wiedergewinnung der tatsachlichen Ablaufe derGeschaftsprozesse (Workflow) (z.B. Bestellungswesen,Auftragsabwicklung etc.)
Uberarbeitung und Neudefinition der Ablaufe
Einfuhrung in das Software-Reengineering: Ziele und Aufgaben
Ziele des Reverse Engineerings
Kontrolle der Komplexitat
Gewinnung alternativer Sichten
Wiedergewinnung verlorener Information
Erkennung von Seiteneffekten
Schaffung hoherer Abstraktionen
Unterstutzung von Wiederverwendung
Einfuhrung in das Software-Reengineering: Ziele und Aufgaben
Haufige Reengineering-Aufgaben
PlattformanpassungAnderung der Programmiersprache
neuer Standard, neue Sprache, neues Paradigma
Benutzerschnittstelle zeichenorientiert hin zu graphischorientiert
Mainframe hin zu Client-Server-Architektur
Datenbankumstellung
Praventive Maßnahmen, wie z.B. Verbesserung des InformationHidings oder Remodularisierung, sind eher selten.
Einfuhrung in das Software-Reengineering: Ziele und Aufgaben
Mass Changes
Anderungen, die weite Teile des Codes bzw. sehr viele Systemebetreffen.
Einfuhrung des Euros
Legacy to Internet Interoperability (Electronic Commerce)Anderung von Reprasentationsformen:
Y2K ProblemErweiterung des Bar-CodesUnix-Datum
→Wunsch nach hohem Automatisierungsgrad
Einfuhrung in das Software-Reengineering: Ziele und Aufgaben
Reengineering in der Praxis
Gegenwartig zur Verfugung stehende Werkzeuge:
grep
symbolische Debugger
Cross-Reference-Tools (fertige Parser, die Basisinformationenextrahieren; z.T. mit Visualisierung durch Graphen)
UML-CASE-Tools, die Klassendiagramme extrahieren
programmierbare Analyse- und Transformationsumgebungenbasierend auf abstrakten Syntaxbaumen (z.B. Refine vonReasoning Systems, DMS von Semantic Designs, RainCode)
Einfuhrung in das Software-Reengineering: Ziele und Aufgaben
Ubersicht uber diese Vorlesung
StatischeProgrammanalysen und-reprasentationen
Dynamische Analysen
Program-Slicing
Refactoring undTransformationen
Software-Produkt-Metriken
Erkennung dupliziertenCodes
Mustersuche
Software-Visualisierung
Begriffsanalyse
Analyse undRestrukturierung vonVererbungshierarchien
Merkmalsuche
Software-Clustering,Architekturrekonstruktionund -validierung
Reengineering-Projekte
Einfuhrung in das Software-Reengineering: Unterschiede zur Vorwartsentwicklung
Software Engineering
“Software engineering is reengineering onthe empty system.”
“Is it?”
Einfuhrung in das Software-Reengineering: Unterschiede zur Vorwartsentwicklung
Unterschiede Forward Eng. / Reengineering
Forward Engineering aufgruner Wiese
Problem noch unklar
Aussagen uber Aufwand,Dauer, Zuverlassigkeit etc.sind schwierigSystem existiert nicht
Entwurf hat vieleFreiheitenim sauberen Entwurf gibtes keine verstecktenAbhangigkeiten
Reengineering
Problem weitgehend klar
Idealerweise: Daten aus derVergangenheit existieren,die Grundlage furSchatzungen darstellenSystem existiert
Genaue Struktur/Qualitatbekannt?Losung ist durchexistierendes SystembeschranktAnderungen konnenglobale Auswirkungenhaben (viele versteckteAbhangigkeiten)
Einfuhrung in das Software-Reengineering: Unterschiede zur Vorwartsentwicklung
Software Engineering & Reengineering
Reengineering beginnt oft bereits wahrend der Erstentwicklung:
neue Anforderungen treffen ein
Missverstandnisse und Unklarheiten werden sichtbar
der Entwurf hat sich als unzureichend erwiesen
Integration anderer Komponenten macht Umstrukturierungennotwendig
Einfuhrung in das Software-Reengineering: Unterschiede zur Vorwartsentwicklung
Weiterfuhrende Literatur
Chikofsky und Cross II. (1990): “Reverse Engineering andDesign Recovery: A Taxonomy”, IEEE Software
definiert Terminologie; ist die begriffliche Grundlage
Baumol u. a. (1996): “Einordnung und Terminologie desReengineering”
fuhrt z.T. deutsche Begriffe ein
Einfuhrung in das Software-Reengineering: Unterschiede zur Vorwartsentwicklung
Bucher I
Demeyer u. a. (2002) stellen eine Reihe von Vorgehensweisenbei typischen Problemen des Reengineerings vor
Muller (1997) bietet eine Einfuhrung in verschiedene Aspektedes Reengineerings (Programmverstehen, Metriken,Sprachkonversion, Restrukturierung, Wiederverwendung,Migration zu objektorientierten Systemen,Managementaspekte)
obwohl meine Vorlesung 1999 in volliger Unkenntnis diesesBuches entstanden ist, ist doch eine große Uberlappung derInhalte festzustellen (das Buch beschreibt aber weniger diekonkreten Techniken)
Fowler (2000) beschreibt so genannte Bad Smells(Code-Anomalien) und zugehorige Refactorings, um sie zubeseitigen
Seacord u. a. (2003) beschreiben Methoden zurModernisierung von Anwendungssystemen; in erster LinieProzess- und Managementfragen werden erlautert
Einfuhrung in das Software-Reengineering: Unterschiede zur Vorwartsentwicklung
Bucher II
Simon u. a. (2006) beschreiben, wie man die Wartbarkeit vonSystemen messen kann; das Ergebnis ist eine Einstufung inAnalogie zu CMMI jedoch fur die innere Produktqualitat
Sneed u. a. (2005) beschreiben organisatorische Aspekte undverschiedene Prozesse fur die Wartung undWeiterentwicklung von Software
Masak (2006) diskutiert verschiedene Aspekte der Wartungund Evolution, insbesondere Beobachtungen, Metriken,Anti-Patterns und Management
Pigoski (1996) behandelt Probleme undManagementlosungen der Software-Wartung
Lehner (1989) beschreibt Probleme undManagementlosungen der Software-Wartung
Einfuhrung in das Software-Reengineering: Unterschiede zur Vorwartsentwicklung
1 Arthur 1988 Arthur, L.J.: Software Evolution: The SoftwareMaintenance Challenge. New York, NY : John Wiley & Sons,1988
2 Baumol u. a. 1996 Baumol, 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: ATaxonomy. 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
Einfuhrung in das Software-Reengineering: Unterschiede zur Vorwartsentwicklung6 Fjeldstad und Hamlen 1979 Fjeldstad, R.K. ; Hamlen, W.T.:
Application Program Maintenance Study: Report to ourRespondents. In: Proceedings of the GUIDE 48. Philadelphia,PA, 1979
7 Fowler 2000 Fowler, Martin: Refactoring: Improving the Designof Existing Code. Addison-Wesley, 2000
8 Lehman 1980 Lehman, Meir M.: Programs, Life Cycles and Lawsof Program Evolution. In: Proceedings of the IEEE, SpecialIssue on Software Evolution 68 (1980), September, Nr. 9,S. 1060–1076
9 Lehner 1989 Lehner, Franz: Nutzung und Wartung vonSoftware. 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
Einfuhrung in das Software-Reengineering: Unterschiede zur Vorwartsentwicklung13 Muller 1997 Muller, Bernd: Reengineering – Eine Einfuhrung.
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 Computer33 (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 Qualitat industriellerSoftwaresysteme 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 bestehenderAnwendungssysteme. dpunkt.verlag, 2005