Softwaretechnik II ST II. 6 Reengineering

Transkript

1 Softwaretechnik II 6 Reengineering Lernziele Wissen, warum und wann Software Reengineering? Wissen, dass Software Reengineering alle Aktivitäten, deren Ziel die qualitative Verbesserung, Aufbereitung und Weiterentwicklung von Software ist, umfasst Prozesse Reverse Engineering, Respezifikation, Restrukturierung und Redokumentation kennen Methodologien, Tools und Praktiken des Software Reengineerings kennen Literatur K. Cremer: Graphbasierte Werkzeuge zum Reverse Engineering und Reengineering, Deutscher Universitätsverlag, 2000 K. A. Ingle: Reverse Engineering, McGraw-Hill Education, 1994 F. Lehner: Softwarewartung und Reengineering, Deutscher Universitätsverlag, IAS, Universität Stuttgart 255

2 Softwaretechnik II 6 Reengineering 6.1 Warum Software Reengineering? 6.2 Reverse Engineering 6.3 Respezifikation 6.4 Redokumentation 6.5 Programmtransformation 6.6 Hinweise für die Praxis 2015 IAS, Universität Stuttgart 256

3 6.1 Warum Software Reengineering? Komplexe, gewachsene Systeme sind (oft) nicht austauschbar! 2015 IAS, Universität Stuttgart 257

4 6.1 Warum Software Reengineering? Ziel: Modernisierung von Altsystemen 2015 IAS, Universität Stuttgart 258

5 6.1 Warum Software Reengineering? Warum Software Reengineering? Aber: Reengineering intereressiert mich nicht, meine Programme funktionieren! Wann wird auf einen neuen Computer oder Sprachstandard umgestellt? Wann wird auf eine andere Programmiersprache umgestellt? Wie lange wird mein Betriebssystem noch unterstützt? Wie offen ist mein System bezüglich der Integration neuer Technologien? Besitze ich eine aktuelle Programmdokumentation? Steigt mein Wartungsaufwand nur, um den Ist-Zustand zu erhalten? Wie gut läßt sich das System in seinem aktuellen Zustand zur Erfüllung gegebener und künftiger Erfordernisse verwenden? Verhält sich das System in allen erdenklichen Situationen robust? 2015 IAS, Universität Stuttgart 259

6 6.1 Warum Software Reengineering? Aufwand für die Pflege von Software-Altsystemen (Live-Mitschrieb) Aufwand für Pflege Sanierung Nutzungsdauer 2015 IAS, Universität Stuttgart 260

7 6.1 Warum Software Reengineering? Kosten Software-Wartung Wartungskosten pro Jahr > 1 Vermögenswert < 10 Sanierungsbedarf hoch = = 10 Jahre Nutzung Sanierungsbedarf gering Vermögenswert = Kosten für Neuentwicklung unter Beachtung des tatsächlichen Funktionsbedarfs 2015 IAS, Universität Stuttgart 261

8 6.1 Warum Software Reengineering? Was ist Software Reengineering? Unter Reengineering versteht man den Prozess der Analyse und der strukturellen Veränderung existierender Programme mit dem Zweck, die qualitativen Eigenschaften Portabilität Wartbarkeit (Produktivität) Wiederverwendbarkeit zu verbessern IAS, Universität Stuttgart 262

9 6.1 Warum Software Reengineering? Das Reengineering umfasst: Die nachträgliche Erzeugung und Verbesserung einer Dokumentation Redokumentation Die nachträgliche Erstellung der Spezifikation, um eine CASE-Umgebung nutzen zu können Respezifikation Die nachträgliche Strukturierung und Formatierung von Programmen, die schlecht lesbar sind Restrukturierung Die Wiederverwendung bewährter Programme Reuse Verbesserung der Möglichkeit, die Programmiersprache zu wechseln Recycle Erweiterung und Änderung von Programmen während des Betriebs Redesign 2015 IAS, Universität Stuttgart 263

10 6.1 Warum Software Reengineering? Wann sind Software Reengineering Maßnahmen notwendig? Technische Anforderungen = verwendete Technik erfüllt fachlich sanieren beibehalten nicht erfüllt aussondern neu entwickeln technisch sanieren nicht erfüllt erfüllt Fachliche Anforderungen = Funktionen 2015 IAS, Universität Stuttgart 264

11 6.1 Warum Software Reengineering? Bewertungsfaktoren für Reengineering Maßnahmen Kosten für Reengineering Kosten für Pflegearbeiten Vermögenswert Zu erwartende Lebensdauer Zukünftige Anforderungen Zeitbedarf für Sanierung Verfügbarkeit von Werkzeugen Mitarbeitersituation 2015 IAS, Universität Stuttgart 265

12 6.1 Warum Software Reengineering? Einflussfaktoren für Reengineering Maßnahmen Wartungskosten Alter der Software Erreichbarkeit Wartungsumgebung Benutzerfreundlichkeit Wartungsressourcen Erfahrung Sicherheitsanforderungen Code- Qualität Technische Abschätzung Wirtschaftliche Abschätzung Risikoabschätzung Andere Abschätzungen Werkzeugunterstützung Ablauf Management Entscheidungsprozess Politik Projektwachstum Geschäftsziele Lebenserwartung des Codes Dokumentation Neue Technologien Wartungsproduktivität Entscheidung 2015 IAS, Universität Stuttgart 266

13 6.1 Warum Software Reengineering? Kosten/Nutzen-Vergleich NW AW DS *( KS E * AW AW NW ) 1 mit DS > 0 Abkürzungen: AW NW DS E KS ZE Alte Wartungskosten/ZE vor Sanierung Neue Wartungskosten/ZE nach Sanierung Dauer der Sanierung in ZE Lebenserwartung in ZE Kosten der Sanierung / ZE Zeiteinheit (z.b.: 1 Monat) 2015 IAS, Universität Stuttgart 267

14 6.1 Warum Software Reengineering? Beispiel für eine Kosten-Nutzen-Analyse AW NW DS / Monat (2 Mitarb.) / Monat (1 Mitarb.) 2 Monate KS Tool Lohnkosten / Monat E 5 Jahre = 60 Monate Faktor: E 1 Jahr = 12 Monate Faktor: 0.75 < IAS, Universität Stuttgart 268

15 6.1 Warum Software Reengineering? Risiken bei Neuentwicklung/Risiken bei Reengineering Neuentwicklung Aufwand/Kosten werden unterschätzt Hohe Fehlerrate in Einführungsphase Neuentwicklung generiert neue Anforderungen Reengineering Entfremdung durch Restrukturierung Parallel zur laufenden Systempflege Je umfangreicher die Sanierungsmaßnahmen sind, um so mehr Fehler sind im neuen System 2015 IAS, Universität Stuttgart 269

16 6.1 Warum Software Reengineering? Reengineering Tätigkeiten Bestandsaufnahme Kosten-Nutzen- Analyse Kosten > Nutzen Planung Respezifikation/Analyse Redokumentation Restrukturierung/ Transformation Abschlusstest Integration 2015 IAS, Universität Stuttgart 270

17 6.1 Warum Software Reengineering? Vorstudie Bestandsaufnahme Feststellung des Gesamtumfangs in LOC Programmiersprache, Dialekte Qualitätsbestimmung Komplexitätsbestimmung Prüfung des Einsatzes von Werkzeugen Verfügbarkeit von qualifizierten Mitarbeitern Kosten/Nutzen-Analyse Aufwandsabschätzung Neuentwicklung Aufwandsabschätzung Reengineering Einsparungen in der Wartungsphase Kostenreduktion durch preiswerte Hardware/ Standardsoftware 2015 IAS, Universität Stuttgart 271

18 6.1 Warum Software Reengineering? Projektplanung Modulweise Umstellung Evolutionäre Integration neuer Module Gemischter Betrieb Zeitunkritisch Komplett-Umstellung Einfrieren des Gesamtsystems Abrupter Wechsel zwischen altem und neuem System Zeitkritisch 2015 IAS, Universität Stuttgart 272

19 6.1 Warum Software Reengineering? Abschlusstest Überprüfung der korrekten Funktion durch Vergleich der Testergebnisse des alten und des neuen Systems Protokollierung Benutzungsschnittstelle Datenbank-Transaktionen Funktionstrace/Datentrace Prozess-I/O 2015 IAS, Universität Stuttgart 273

20 6.1 Warum Software Reengineering? Reengineering Vorgehensweisen Spezifikation 1 Redesign Spezifikation 2 Abstraktion Generierung Ursprung z. B.: Quellprogramm in Fortran, schriftliche Unterlagen, Know-How Transformation Restrukturierung Metriken Übersetzung Redokumentation Instrumentierung Ergebnis z.b.: Quellprogramm in C, Übersichtsdiagramme, strukturierter Code 2015 IAS, Universität Stuttgart 274

21 Frage zu Kapitel 6.1 Frage zu Kapitel 6.1 Welche qualitativen primären Eigenschaften soll Software Reengineering verbessern? Antwort f Dokumentation Reaktionszeit Produktivität Wiederverwendbarkeit 2015 IAS, Universität Stuttgart 275

22 Softwaretechnik II 6 Reengineering 6.1 Warum Software Reengineering? 6.2 Reverse Engineering 6.3 Respezifikation 6.4 Redokumentation 6.5 Programmtransformation 6.6 Hinweise für die Praxis 2015 IAS, Universität Stuttgart 276

23 6.2 Reverse Engineering Was ist Reverse Engineering? Reverse Engineering beinhaltet die Analyse existierender Programme mit dem Zweck: Die Komponenten und deren Beziehung zu bestimmen Das Programmsystem in anderer Form und auf höherer Abstraktionsebene zu beschreiben IAS, Universität Stuttgart 277

24 6.2 Reverse Engineering Reverse Engineering Anforderungs- Analyse REQ 1 REQ 2 REQ 3 Requirementspezifikation Respezifikation + Reverse Engineering manuelle Interaktion Programmanalyse Dokumentation PROG 1 Grobentwurf MOD 1 MOD 2 MOD 3 F 1 F 2 F 3 Entwurfsspezifikation (high level) Respezifikation + manuelle Interaktion Respezifikation Feinentwurf Entwurfsspezifikation (low level) Implementierung Forward Engineering Programmquelle 2015 IAS, Universität Stuttgart 278

25 Softwaretechnik II 6 Reengineering 6.1 Warum Software Reengineering? 6.2 Reverse Engineering 6.3 Respezifikation 6.4 Redokumentation 6.5 Programmtransformation 6.6 Hinweise für die Praxis 2015 IAS, Universität Stuttgart 279

26 6.3 Respezifikation Respezifikation Respezifikation ist Bestandteil des Reverse Engineering Aus allgemeinen Informationen, der vorhandenen Dokumentation, dem Quelltext und dem funktionalen Verhalten des Programms wird die Beschreibung der Anforderungen und des Entwurfs nachempfunden Anforderungsspezifikation Entwurfsspezifikation Quellcode und Dokumentation 2015 IAS, Universität Stuttgart 280

27 6.3 Respezifikation Vorgehensweise bei der Respezifikation Schritt 1: Analyse des Quellcodes bezüglich der Struktur Schritt 2: Ergänzung der Struktur durch funktionale Aspekte Schritt 3: Vollständige Beschreibung, welche die Beziehungen zwischen den Anforderungen, dem Entwurf und dem Quellcode beschreibt Schritt 4: Überprüfung der Respezifikation 2015 IAS, Universität Stuttgart 281

28 6.3 Respezifikation Zusammenhang zwischen Quellcode, Entwurf und Anforderungen REQ 400: REQ 410: REQ 420: Anforderungs- Spezifikation Funktion X Funktion Y A X1 Y1 C X2 X3 X4 Y2 Y3 D Entwurfs- Spezifikation B X5 X6 X7 E { Quellcode { 2015 IAS, Universität Stuttgart 282

29 Frage zu Kapitel 6.3 Frage zu Kapitel 6.3 In welchen Situationen ist der Einsatz von Reverse Engineering Maßnahmen sinnvoll? Antwort f Wenn die bestehende Software nicht weggeworfen werden kann Wenn die vorhandene Datenstruktur wieder verwendet werden kann Wenn die Kosten der Neuentwicklung signifikant hoch sind 2015 IAS, Universität Stuttgart 283

30 Softwaretechnik II 6 Reengineering 6.1 Warum Software Reengineering? 6.2 Reverse Engineering 6.3 Respezifikation 6.4 Redokumentation 6.5 Programmtransformation 6.6 Hinweise für die Praxis 2015 IAS, Universität Stuttgart 284

31 6.4 Redokumentation Redokumentation Unter Redokumentation versteht man die nachträgliche Erstellung und Aktualisierung der Programmdokumentation Sichten: Kontrollfluss Datenfluss Programm Datenstrukturen Aufrufstruktur 2015 IAS, Universität Stuttgart 285

32 6.4 Redokumentation Nutzen einer Redokumentation Besseres Verständnis, mehr Übersicht Transparenz für neue/andere Mitarbeiter Gute Dokumentation erhöht Akzeptanz beim Auftraggeber Höhere Wiederverwendbarkeit durch eine leicht verständliche, aktuelle und präzise Dokumentation 2015 IAS, Universität Stuttgart 286

33 6.4 Redokumentation Redokumentation Der Ist-Zustand eines vorhandenen Programms wird am Projektende oder in der Wartungsphase nachträglich dokumentiert Nassi- Shneidermann- Diagramme Crossreferenzlisten Dokumentation andere Informations- Quellen + REVERSE ENGINEERING Quellprogramm 2015 IAS, Universität Stuttgart 287

34 6.4 Redokumentation Alternativen: Manuell, werkzeugunterstützt: Quelltext-Formatierer Struktogramm-Generatoren Respezifikations- und Dokumentationswerkzeuge Beispiele für Werkzeuge: Goose Menge von Werkzeugen zur Analyse des Entwurfs eines objektorientierten Softwaresystems, die am FZI Karlsruhe entwickelt wurden SRF Generator Ein Kommandozeilenwerkzeug zur Fact Extraction aus Java Systemen TableGen Ein Kommandozeilenwerkzeug für C/C++ Systeme Film: Reverse Engineering mit Rose IAS, Universität Stuttgart 288

35 Frage zu Kapitel 6.4 Frage zu Kapitel 6.4 Welche Nutzen bringt die Redokumentation? Antwort f Besseres Verständnis und mehr Übersicht Anzeigen eines Programmablaufplans Erhöhung der Akzeptanz beim Auftraggeber Transparenz für neue/andere Mitarbeiter 2015 IAS, Universität Stuttgart 289

36 Softwaretechnik II 6 Reengineering 6.1 Warum Software Reengineering? 6.2 Reverse Engineering 6.3 Respezifikation 6.4 Redokumentation 6.5 Programmtransformation 6.6 Hinweise für die Praxis 2015 IAS, Universität Stuttgart 290

37 6.5 Programmtransformation Sprachtransformation höhere Programmiersprache höhere Programmiersprache Assembler manuell automatisch interaktiv Assembler 2015 IAS, Universität Stuttgart 291

38 6.5 Programmtransformation Vorgehensweise bei der Programmtransformation Quellprogramm (z.b. FORTRAN) Preprozessor Scanner Parser Symboltabelle Strukturtabelle Quellcode- Generator Bereitstellung der Laufzeitroutinen aus der alten Programm- Umgebung in der neuen Programmiersprache Laufzeitbibliothek Quellprogramm (z.b. C) Übersetzbares und ablauffähiges Programmsystem 2015 IAS, Universität Stuttgart 292

39 Softwaretechnik II 6 Reengineering 6.1 Warum Software Reengineering? 6.2 Reverse Engineering 6.3 Respezifikation 6.4 Redokumentation 6.5 Programmtransformation 6.6 Hinweise für die Praxis 2015 IAS, Universität Stuttgart 293

40 6.6 Hinweise für die Praxis Reengineering bedeutet: Investition zur Sicherung alter Investitionen Vorteile des Reengineerings Möglichkeit der Rettung großer getätigter Softwareinvestitionen Steigerung der Produktivität bei der Softwarewartung und der Weiterentwicklung Portabilität durch Verwendung von Standards Kostenreduktion durch Wiederverwendung bewährter Komponenten Einfache Integration neuer Technologien Höhere Zufriedenheit der Mitarbeiter Einfache Adaption von Produkten Verbesserung der Softwarequalität 2015 IAS, Universität Stuttgart 294

41 6.6 Hinweise für die Praxis Grenzen des Reengineerings Einschränkungen beim Gebrauch automatisch arbeitender Werkzeuge: Programmtransformation Neuer Quellcode ist schwierig zu warten Restrukturierung unterschiedliche Sichtweisen Programm wird größer Effizienz nimmt ab Respezifikation, Dokumentation Nur formale (syntaktische) Sprachelemente werden ausgewertet Einschränkungen bei der manuellen Arbeit lange Dauer fehleranfällig unbeliebt 2015 IAS, Universität Stuttgart 295

42 Vorbereitungsfragen Vorbereitungsfragen zu 6 Frage 1: Reengineering (WS 03/04) Im Rahmen einer großen Softwareinvestition wurde vor 10 Jahren eine verfahrenstechnische Anlage automatisiert. In diesem Jahr müssen Teile der Anlage durch weiterentwickelte Hardware ersetzt werden. Es besteht die Möglichkeit die Software komplett neu zu entwickeln oder sie zu sanieren. Welches Verfahren schlagen Sie vor? Begründen Sie Ihre Aussage. Frage 2: Reengineering (WS 05/06) Ein Softwaresystem, das zur Steuerung einer verfahrenstechnischen Anlage eingesetzt wird, verursacht Wartungskosten pro Jahr. Die Neuentwicklung kostet 10 Millionen. Besteht ein Sanierungsbedarf? Begründen Sie Ihre Aussage IAS, Universität Stuttgart 296