Manchmal ist es nicht mehr damit getan, alten Code zu erweitern: Eine Rundumerneuerung muss her. Dieser Beitrag beschreibt Vorgehen rund um das Embedded-Software-Redesign und erläutert dabei die Begriffe Reverse-Engineering, Refactoring und Reengineering.
Veranstaltungsformen wie Workshops eignen sich ideal, um mit den passenden Wissensträgern die Anforderungen zu erfassen und zu dokumentieren. Um Anforderungen aus dem Programmcode abzuleiten, existieren keine Tools am Markt. Hier ist manuelle Arbeit gefragt. Erfahrungsgemäß ist es nicht möglich, 100% aller in der Software implementierten Anforderungen zu erfassen.
Zu den erfassten Anforderungen werden nun die zugehörigen Abnahmekriterien entwickelt und dokumentiert. Neben manchen UML-Tools eignen sich ALM- (Application Lifecycle Management) bzw. PLM- (Product Lifecycle Management) Tools wie z.B. IBM DOORS zur Dokumentation der Anforderungen und Abnahmekriterien.
Bild 4: Flowchart-Entscheidungshilfen fürs Software-Reverse-Engineering, Teil 2
Idealerweise lässt sich auf Basis der Abnahmekriterien ein automatisierter und nachvollziehbarer Softwaretest durchführen, um das nach außen beobachtbare Verhalten der Software zu überprüfen. Während des Software-Redesigns darf sich dieses Verhalten genauso wenig ändern wie die Anforderungen und Abnahmekriterien. Als Kompromiss beschränkt sich das Reverse-Engineering in der Praxis häufig „nur“ auf die Erstellung der Software-Dokumentation.
Sind die Voraussetzungen für ein erfolgreiches Embedded-Software-Redesign geschaffen, können Sie mit dem Software-Refactoring beginnen. Software-Refactoring verbessert die interne Softwarestruktur und Codierung der fertigen Software, ohne dabei das von außen beobachtbare Verhalten zu verändern.
Man unterscheidet zwischen „kleinem” und „großem” Refactoring. Ein kleines Refactoring bezeichnet Änderungen auf der Sourcecode-/ Designebene, das große ist für Änderungen auf der Architekturebene zuständig. Die Konsequenz eines großen Refactorings sind automatisch mehrere kleine Refactorings.
Bild 5: Voraussetzungen für ein erfolgreiches Redesign mit Refactoring
Wie bereits erwähnt, darf sich die Embedded-Software nach einem Refactoring nach außen hin nicht anders als zuvor verhalten. Dies sollte nach jedem Refactoring durch erneutes Ausführen der unveränderten Softwaretests überprüft werden. Ergänzen Sie bitte erst nach einem erfolgreichen Refactoring neue Features.
Das Vorgehen im Embedded-Software-Refactoring kann wie folgt aussehen.
Bild 6: Embedded-Software-Refactoring
Unter Berücksichtigung der Zieldefinition identifizieren Sie Refactoring-Potenziale, sogenannte „Smells“, in der Embedded-Software (siehe folgende Tabelle):
| Refactoring-Potenzial „Smell“ | Refactoring-Kategorie | Refactoring-Auswahl |
| Large Method [3] ->Kleines Refactoring |
Simplify Conditional Expression [3] | Decompose Conditional [3] |
| Betriebssystem-Portierung nicht möglich -> Großes Refactoring |
Architektur-Schichtenmodell erweitern | OSAL (Operating System Abstraction Layer) einziehen |
Tabelle 1: Refactoring-Beispiele
In vorgefertigten Refactoring-Katalogen finden Sie einzelne Refactorings in Kategorien unterteilt. Dort wählen Sie das für Ihr Problem passende Refactoring aus und implementieren es. Gerade in der Embedded-Software ist der Refactoring-Bedarf häufig sehr speziell, so dass Sie Ihre eigenen Refactorings und Kategorien selbst entwickeln müssen.
Ein moderner Programmcode-Editor wie Eclipse oder dazu passende Plug-Ins unterstützen bei der Refactoring-Implementierung. Dazu müssen Sie den zu refaktorierenden Programmcode selektieren; eine Menüauswahl bietet Ihnen passende Refactorings an und setzt diese direkt bei der Auswahl um.
Große Refactorings setzen wir manuell in kleinen und geplanten Schritten um. Nehmen Sie Änderungen auf der Software-Codeebene vor, müssen Sie meist auch die Unit-Tests adaptieren.
Wichtig: In vielen Fällen lässt sich erst während des Refactorings der Software bewerten und entscheiden, ob sie tatsächlich noch sinnvoll refaktoriert werden kann oder ob es nicht erfolgversprechender ist, die Software neu zu entwickeln.
Zusammenfassend unterteilt sich das Software-Redesign in ein optionales Reverse-Engineering, falls eines der dafür benötigten Artefakte fehlt. Anschließend führen Sie so lange Refactorings durch, bis Sie Ihr Ziel erreicht haben.
Als weiterführende Quelle zum Thema Refactoring möchte ich Martin Fowler nennen. Neben seinem Buch “Refactoring” ist auch sein Refactoring Online Portal empfehlenswert.
Bild 7: Flowchart zum Software-Redesign
Sind alle Refactorings umgesetzt und die Embedded-Software verhält sich wie zuvor (Nachweis über Softwaretests), dann müssen Sie spätestens jetzt die Software-Dokumentation anpassen. Nur so bleibt die Konsistenz der Embedded-Software-Artefakte erhalten.
Profi-Tipp: Übertragen Sie die durchgeführten Refactorings in Richtlinien, damit sich die gleichen Fehler nicht nochmals einschleichen. Abhängig vom Refactoring ergänzen Sie damit zusätzlich Ihre Architektur-, Design-, Modellier- und/oder Codier-Richtlinien.
Manchmal reicht ein Software-Redesign im Sinne von Reverse-Engineering und Refactoring nicht aus
Ein noch nicht ausgereiftes Entwicklungsvorgehen verursacht teilweise auch die Defizite der inneren Softwarequalität. In diesem Fall müssen Sie das Entwicklungsvorgehen optimieren, was wir als Embedded-Software-Reengineering bezeichnen. Ein generischer Ansatz, dies zu tun, kann wie folgt dargestellt aussehen:
Bild 8: Embedded-Software-Reengineering
Die Optimierungsziele ergeben sich aus den aktuellen Herausforderungen, die im Entwicklungsvorgehen nicht gelöst sind. Unternehmensabhängig ist das Entwicklungsvorgehen nicht dokumentiert. Oder es ist dokumentiert, wird aber durch die Mitarbeiter nicht oder unterschiedlich gelebt. Insbesondere in diesen Fällen sollten wir uns das tatsächliche Entwicklungsvorgehen bewusst machen.
Danach hat jeder Beteiligte die gleiche Sicht auf das Entwicklungsvorgehen, und die zielbezogene Analyse ist durchführbar. Hierbei gilt es, die Ursachen für die Defizite zu finden. Um die Ursachen zu eliminieren, optimieren wir zielbezogen das Entwicklungsvorgehen.
Nun muss sich das optimierte Vorgehen in der Praxis bewähren. In einem Pilotprojekt wenden wir das optimierte Entwicklungsvorgehen an und verifizieren am Projektende, ob wir die ursprünglich definierten Optimierungsziele erreicht haben. Wenn nein, müssen wir einen weiteren Optimierungslauf mit einem nächsten Pilotprojekt ausführen.
Haben wir unser Optimierungsziele erreicht, dann beginnen wir wieder mit der Definition neuer Optimierungsziele. Embedded-Software-Reengineering ist ein kontinuierlicher Prozess.
Checkliste: Wie lässt sich ein nötiges Redesign vermeiden?
Die Notwendigkeit von Embedded-Software-Redesigns lässt sich mit folgenden Maßnahmen effektiv minimieren:
- Hohe Qualifikation der Mitarbeiter
- Bewusstsein der Wichtigkeit von Anforderungen, Architektur und Design im Team wecken
- Embedded-Software mit der UML (Unified Modeling Language) modellieren und gleichzeitig dokumentieren
- Eigene Architektur-, Design-, Modellier- und Codier-Richtlinien erstellen
- Auf allen Ebenen (Management, Projektleitung und Entwicklung) zukunftsorientiert denken und handeln
- Entwicklungsteams bestehend aus Elektrotechnikern und (Technischen-) Informatikern bilden
- Entwicklungsvorgehen kontinuierlich anpassen und optimieren
- Der Clean Code Developer Initiative folgen
- Software-Erosion dauerhaft automatisiert durch Tooleinsatz vermeiden, z.B. Bauhaus Suite von Axivion
____________________________________________________
Der erste Teil der Beitragsreihe widmet sich der Frage, wann es nötig ist, alten Code komplett zu überarbeiten, und betrachtet die Kriterien Prozessqualität, äußere Produktqualität und innere Produktqualität. Der zweite Teil beleuchtet die Frage, ob Änderungen und Erweiterungen der aktuellen Software ohne Seiteneffekte sehr zeitintensiv oder nicht mehr möglich sind.
Mehr lesen
Embedded-Software-Redesign Guide:
Teil 1 „Defizite und Auslöser“
Teil 2 „Notwendigkeit erkennen“
Weiterführende Informationen
MicroConsult Training & Coaching zum Thema Softwarequalität
MicroConsult Fachwissen zum Thema Softwarequalität
