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, koschke@tzi.de

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