23 Reengineering 23.1 Software-Evolution 23.2 Reengineering 23.3 Refactoring 24.4 Erblasten, Legacy Software

Motivation Wartung: auf Wunsch oder im Auftrag der Anwender Reengineering: ermöglicht oder erleichtert die Wartung Reengineering ist also eine software-interne Maßnahme. Versetzt das System in einen wartbaren Zustand. Der Kunde profitiert davon nur indirekt. Reengineering ist spätestens dann erforderlich, wenn die Software verändert werden muss, aber nicht (mit vertretbarem Aufwand) verändert werden kann, weil die Wartungsqualität schlecht ist.

23.1 Software-Evolution

Laws of Software Evolution In den Siebzigerjahren: Tendenz, aus dem Software Engineering eine Wissenschaft mit Naturgesetzen und Formeln zu machen. Vgl. Halsteads „Software Science“ von 1977 Aussagen gelten für die P- und E-Programme in der Taxonomie von Lehman, also für Software, deren Anforderungen nicht stabil sind, sondern sich mit der Zeit ändern. law of continuing change — A system that is used undergoes continuing change until it becomes more economical to replace it by a new or restructured system. law of increasing entropy — The entropy of a system increases with time unless specific work is executed to maintain or reduce it. Lehman, Belady (1985)

Software Evolution Software-Evolution ist die wiederholte Anpassung einer Software an veränderte Anforderungen und Umgebungsbedingungen. Lässt man die Evolution zu, bewirkt sie einen Qualitätsverlust der Software. Lässt man sie nicht zu, so wird die Software nutzlos. „Gesetz“ 1 sagt aus, dass die Änderung stattfindet. „Gesetz“ 2 fügt hinzu, dass der Effekt dieser Änderung negativ ist, wenn man dem nicht mit zusätzlichem Aufwand entgegenwirkt. D. Parnas bezeichnet diesen Effekt als Software-Alterung. Alternde Software zeigt die folgenden Symptome: Die Software wird fehleranfällig. Es wird schwieriger, sie neuen Anforderungen anzupassen. Die Leistung (die Effizienz) lässt nach. Die Architektur degeneriert.

Gründe für die Alterung Zwei wichtige Gründe für diese Symptome sind: Komponenten werden durch die wiederholten Modifikationen immer größer und komplexer Neue Komponenten werden irgendwie in die dafür eigentlich ungeeignete Architektur integriert und mit den existierenden Komponenten verbunden. Parnas empfiehlt: Software sollte so konstruiert werden, dass sie weiterentwickelt und angepasst werden kann. Dieser Ansatz wird als Design for Change bezeichnet. Trotzdem kann der Prozess der Software-Alterung nicht aufgehalten, sondern lediglich verlangsamt werden.

Das Entropie-Prinzip der Thermodynamik Die Metapher der Entropie: Die Entropie ist ein Maß für die Unordnung.

Beispielhafter Alterungsprozess Eine wichtige Gegenmaßnahme zum schleichenden Qualitätsverlust ist das Reengineering.

23.2 Reengineering

Begriffe Reverse Engineering is the process of analyzing a system to identify the system’s components and their interrelationships and create representations of the system in another form or at a higher level of abstraction. Re-structuring is a transformation from one form of representation to another at the same relative level of abstraction. The new representation is meant to preserve the semantics and external behavior of the original. Reengineering is the examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form. Forward Engineering is the traditional process of moving from high-level abstractions and logical, implementation-independent designs to the physical implementation of a system. Chikofsky, Cross (1990)

Zusammenhänge Die Kombination aus Reverse Engineering, Re-structuring und Forward Engineering bezeichnet man als Reengineering. Reengineering ist also eine Veränderung der Software, die auf die Verbesserung der Wartbarkeit zielt. Andere nichtfunktionale Qualitäten, insbesondere die Effizienz, können dabei ebenfalls verbessert werden. Die Funktionalität bleibt unangetastet. Keipinger (2000): Reengineering = Reverse Engineering + Δ + Forward Engineering

Vorgehensweise - 1 Reengineering muss immer dann durchgeführt werden, wenn man die Software weder unverändert weiternutzen noch komplett wegwerfen und ersetzen kann oder will. Typische Ausgangssituation: Ein altes Software-System, zu dem es keine oder nur noch veraltete separate Dokumente gibt, soll erweitert werden, soll auf eine neue System-Software (z.B. Betriebssystem, Middleware) oder Programmiersprache portiert werden, soll partiell ersetzt oder einer erheblichen Veränderung unterzogen werden.

Vorgehensweise - 2

Techniken Beim Reverse Engineering werden aus den noch verfügbaren Informationen (typisch der Code und veraltete Dokumente) abstraktere Modelle hergeleitet. Dazu müssen die grobe Ablaufstruktur, die Datenstrukturen, die Module und die Aufrufbeziehungen identifiziert werden. In extremen Fällen ist nur noch der Objektcode vorhanden. Wichtige Techniken: Nachdokumentation und Wiederentdeckung der Architektur (design recovery). Redocumentation is the creation or revision of a semantically equivalent representation within the same relative abstraction level. Design recovery recreates design abstractions from a combination of code, existing documentation (if available), personal experience, and general knowledge about problem and application domain. Chikofsky, Cross (1990)

Ziele und Erkenntnisse Vorhandener Code soll in einer übersichtlichen Form dargestellt werden, um ihn leichter verstehen zu können. Erkennung höherer Strukturen (z. B. Schleifen, Module, Parameter) Querübersetzung in eine moderne Sprache. Erkenntnisse Design Recovery kann nur erfolgreich sein, wenn neben dem Code auch noch Wissen über die Anwendungsentwicklung verfügbar ist. Der Traum von einer automatischen Strukturverbesserung hat sich bis heute nicht erfüllen lassen.

23.3 Refactoring

Idee Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written. Martin Fowler (1999), S. xvi Das Refactoring wird präventiv eingesetzt: Wenn eine Änderung mit den bestehenden Strukturen kollidiert, ändert man zunächst die Strukturen so, dass die folgende Änderung keinen negativen Effekt hat. Die Software wird in einem systematischen Prozess durch kleine Umbaumaßnahmen verbessert, ohne dass sich das beobachtbare Verhalten verändert.

Vorgehensweise

Code-Refactoring Wenn der Code „stinkt“ (code smell), ist ein Refactoring sinnvoll. Dabei werden immer wieder die gleichen Transformationen durchgeführt. Fowler hat dazu Muster, die „Mechanics“, eingeführt. „Mechanics“ von Fowler (Gruppen): Umbau auf Methodenebene Umbau der Verantwortlichkeiten zwischen Objekten Umbau der Datenorganisation Vereinfachen von Bedingungsausdrücken. Vereinfachen von Methodenaufrufen Umbau von Vererbungshierarchien Einige dieser Änderungen können mit Hilfe von Werkzeugen durchgeführt werden.

Architektur-Refactoring Roock und Lippert (2004) klassifizieren Schwachstellen, die auf der Architekturebene objektorientiert konstruierter Systeme liegen. Diese werden analog als »architecture smells« bezeichnet Klassifikation gemäß Architektur-Metamodell Schwachstellen in Benutzungsgeflechten: z.B. zyklische Beziehungen Vererbungshierarchien: z.B. parallele Hierarchien Paketen: z.B. zu große und zu kleine Pakete Subsystemen: z.B. Größe, Schnittstellengestaltung Schichten: z.B. Aufwärtsreferenzen

23.4 Erblasten, Legacy Software

Definition legacy system — A large software system that we don't know how to cope with but that is vital to our organization. Bennett (1995) Wird Software über viele Jahre eingesetzt und gewartet, dann wird ihre Struktur immer schlechter. Die Wartung solcher Software ist extrem schwierig, aufwändig und riskant. Eine Software-Erblast ist also gekennzeichnet, dass sie dringend gebraucht, aber von niemandem verstanden wird.

Eigenschaften Folgende Merkmale sind für eine Software-Erblast typisch: Sie ist sehr groß (106 LOC oder mehr) und alt (älter als 10 Jahre). Die Entwickler und die Architekten der Software sind nicht mehr verfügbar. Die zur Entwicklung eingesetzten Methoden und Sprachen sind veraltet und den verfügbaren Mitarbeitern kaum bekannt. Die Software läuft und hat für ihren Besitzer strategische Bedeutung. Die Dokumentation ist obsolet oder fehlt ganz. Die Software basiert auf veralteter Hardware und System-Software.

Erneuern oder Ablösen einer SW-Erblast Die Erneuerung oder Ablösung einer Software-Erblast ist schwierig und mit Risiken verbunden. Typisch müssen dabei folgende Anforderungen erfüllt werden: Die neue Software muss die alte voll ersetzen, also abwärtskompatibel sein. Die neue Software muss zusätzlich alle aktuellen Anforderungen implementieren. Dazu zählen neue funktionale, aber auch nichtfunktionale Anforderungen. Die Daten, die die alte Software be- oder verarbeitet, müssen übernommen werden. Eine längere Unterbrechung des Betriebs zur Umstellung ist ausgeschlossen.

Ansätze zum Nutzen oder Ablösen Ansätze, um eine Software-Erblast weiter zu nutzen oder abzulösen: Verpacken (wrapping) Wenn eine alte Software oder Komponente stabil arbeitet und voraussichtlich nicht mehr wesentlich verändert werden muss, kann sie so in eine Hülle (»Wrapper«) eingebettet werden, dass die übrige Software nur noch mit der Hülle kommuniziert. Die alte Software wird also als moderne »verkleidet«. Migration Die alte Software wird schrittweise erneuert und/oder ersetzt. Neuentwicklung (re-development) Die Funktionalität der alten Software wird neu implementiert, dann wird die alte Software durch die Neuentwicklung ersetzt. Es sind auch Mischformen möglich.

Migration einer Software-Erblast Voraussetzung: Zerlegung in Komponenten, die unabhängig voneinander migriert werden können. Festlegung einer Reihenfolge, dann für jede Komponente: Reverse Engineering (Was leistet die Komponente?) Architektur für die neue Komponente wird entworfen; Teile der alten Komponente können unter Umständen wiederverwendet werden. Zur Verbindung mit den alten Teilen evtl. Adapter (Gateways) Implementierung der neuen Komponente Konvertierung der Datenbestände; evtl. in Teilschritten Test der neuen Komponente, Integration, Betrieb Vorteil: kein Übergangszustand; Nachteil: Risiko! Alternative: Big Bang (Ablösung auf einen Schlag)