Software-Qualität

So lässt sich Software-Erosion verhindern

04.12.2007 | Autor: Thomas Eisenbarth*

Der langsame Verfall von Software ist oft der Grund für schleichende Qualitätsmängel. Der erste Punkt, an dem diese so genannte Software-Erosion ansetzt, ist die wachsende Kluft zwischen der geplanten Sofware-Architektur und ihrer Implementierung. Daher sichert die kontinuierliche Prüfung der Architektur durch Werkzeuge den langfristigen Projekterfolg.

Bild: brit/pixelio.de

Wie Meir M. Lehman und Laszlo A. Belady bereits in den siebziger Jahren des letzten Jahrhunderts untersucht haben, wird erfolgreiche Software über einen langen Zeitraum entwickelt. Entwickler arbeiten in der Regel direkt am Code und können globale Auswirkungen schlecht einschätzen: „Wie schlimm kann es sein, wenn ich hier direkt auf Variable x zugreife? Was, wenn ich hier Funktion y aufrufe, die ich eigentlich nicht kennen dürfte?“

Wie lässt sich prüfen, ob die Architekturbeschreibung eingehalten wurde?

Ergänzendes zum Thema

 + So lässt sich innere Softwarequalität sicherstellen

Um innere Softwarequalität sicherzustellen wird am besten eine Architekturprüfung mit anderen Analysen kombiniert. Dazu gesellen sich weniger bekannte ...

Um innere Softwarequalität sicherzustellen wird am besten eine Architekturprüfung mit anderen Analysen kombiniert. Dazu gesellen sich weniger bekannte Techniken. Die Methoden im Überblick:

• Architekturprüfung: Es entsteht keine Kluft mehr zwischen der beabsichtigten Architektur und der Implementierung im Code.
• Klonerkennung: Kopierte Code-Stücke können Fehler verschleppen und den Codeumfang vergrößern.
• Zyklenerkennung: Zyklen erschweren das Verständnis, weil um einen Teil des Codes, der im Zyklus liegt zu verstehen, alle Anteile des Codes im Zyklus verstanden werden müssen.
• Stylechecks: Einheitliche Codierrichtlinien erleichtern die Einarbeitung und vermeiden Flüchtigkeitsfehler.
• Metriken: Wertemäßige Ausreißer und zeitliche Verläufe erleichtern eine Beurteilung von weitgehend unbekannten Bereichen im Code.
• Erkennung toten Codes: Wie Klone vergrößert toter Code die Codebasis. Es kann auch sein, dass Code stirbt, der nicht sterben sollte.

 + Was bedeutet Erosion der Software-Architektur?

Für die Erstentwicklung eines Software-Systems ist eine durchgängige und klare Architektur vorgegeben, die größtenteils auch so implementiert wird. Jedes Software-System wird jedoch in seinem Lebenszyklus erweitert, gewartet und von Fehlern befreit. Dabei wird immer weniger auf die Architektur geachtet, beispielsweise, weil neue Personen mit der Entwicklung betraut werden. Es entsteht eine wachsende Kluft zwischen der gewollten Architektur und der Implementierung. Dieser Prozess des Verfalls der Struktur wird auch Architekturerosion genannt.

Die Auswirkungen der Architekturerosion werden anfänglich unterschätzt, und auf Grund von Zeitmangel wird oft nichts zu ihrer Eindämmung unternommen. Wird nicht aktiv entgegen gesteuert, führt dieser Prozess jedoch zwangsläufig dazu, dass ein Software-System immer mehr verdeckte Abhängigkeiten zwischen seinen Bestandteilen aufweist. Das Software-System kann dann nicht mehr vollständig erfasst und verstanden werden. Änderungen werden schlechter planbar, schwerer zu implementieren und aufwendiger zu testen. Es werden aufwendige Umgehungslösungen implementiert, die wiederum weitere verdeckte Abhängigkeiten einführen. Die Codequalität nimmt ab, und nachfolgende Änderungen werden noch aufwendiger.

Eine Architekturbeschreibung gibt vor, aus welchen Komponenten eine Software aufgebaut ist und wie diese miteinander in Beziehung stehen sollen. Die Einhaltung der Architekturbeschreibung lässt sich mithilfe des hierarchischen Reflexionsmodells prüfen. Dazu wird die Architekturbeschreibung wie eine Blaupause über den Code gelegt (Bild 1). Die Beziehungen, die im Code vorkommen, werden automatisch mit den spezifizierten Beziehungen in der Architektur abgeglichen.

Findet sich eine durch die Architektur vorgegebene Beziehung im Code wieder, so liegt eine Konvergenz vor. Gibt es eine spezifizierte Beziehung in Code nicht, so spricht man von einer Absenz. Gibt es andererseits eine Beziehung im Code, die durch die Architektur nicht gedeckt ist, so spricht man von einer Divergenz. Absenzen und Divergenzen stellen Verstöße gegen die Architektur dar. Auf diese Weise stellt die Architekturprüfung einen Test für die innere Softwarequalität dar (Bild 2).

Wie geht man mit Verstößen gegen die Architektur um?

• Die Zahl der Divergenzen erlaubt Rückschlüsse auf die Wartbarkeit einer Software.

• Die Divergenzen geben eine vorzügliche Liste mit Stellen vor, an denen man mit der Verbesserung der inneren Softwarequalität beginnen kann.

• Ein Blick auf die Divergenzen in einem Bereich, in dem man eine Entwicklungstätigkeit plant, gibt Aufschluss, mit welchen Problemen zu rechnen ist.

Woher kommt die Architekturbeschreibung?

Social Networks: