Software-Qualität

So lässt sich Software-Erosion verhindern

04.12.2007 | Autor / Redakteur: Thomas Eisenbarth* / Martina Hafner

Bild: brit/pixelio.de
Bild: brit/pixelio.de

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.

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?“

Auf diese Weise werden Beziehungen in den Code eingebaut, die es nicht geben dürfte und die Software weicht immer stärker von der geplanten Architektur ab, die Erosion nimmt ihren Lauf. Bei langen Entwicklungszeiträumen ist es wichtig Architekturvorgaben einzuhalten, weil Verstöße dagegen sich zwar erst später aber dafür umso stärker auswirken.

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

Während die äußere Software-Qualität im klassischen Software-Test sichergestellt wird, gibt es zur Sicherung der inneren Qualität oft kein spezielles Rollenbild im Entwicklungsprozess. Deshalb bleiben Verstöße gegen die Architektur in der lokalen Entwicklung häufig unbemerkt. Man spürt sie nur indirekt als Probleme, denen man mit Workaround entgegen tritt, z. B. „Die Variable x kann ich nicht nutzen, weil sie je nach Kontext Verschiedenes bedeutet. Die Funktion y benötigt ein Flag, je nach dem, von wo sie aufgerufen wird.“

Bild 1: Die Einhaltung der Architekturbeschreibung lässt sich mithilfe des hierarchischen Reflexionsmodells prüfen. Dazu wird die Architekturbeschreibung wie eine Blaupause über den Code gelegt: Software-Architektur (links) und Code (rechts) mit Variablen und Funktionen und deren Beziehungen.
Bild 1: Die Einhaltung der Architekturbeschreibung lässt sich mithilfe des hierarchischen Reflexionsmodells prüfen. Dazu wird die Architekturbeschreibung wie eine Blaupause über den Code gelegt: Software-Architektur (links) und Code (rechts) mit Variablen und Funktionen und deren Beziehungen.

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.

Bild 2: Vergleich von beabsichtigter Architektur und Ergebnis der Prüfung bzgl. des Codes aus Bild 1. Absenz und Divergenzen stellen Verstöße gegen die Architektur dar.
Bild 2: Vergleich von beabsichtigter Architektur und Ergebnis der Prüfung bzgl. des Codes aus Bild 1. Absenz und Divergenzen stellen Verstöße gegen die Architektur dar.

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 Divergenzen im Code zu kennen, ist aus drei Gründen wichtig:

  • 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.

Absenzen sind in der Regel deutlich weniger problematisch, da sie selbst keine falschen Abhängigkeiten in sich bergen. Die Zeit der verdeckten Abhängigkeiten, auf die man “so nebenbei” stößt, ist damit vorbei. Eine Trendanalyse der Verstöße ist außerdem ein hervorragender Gradmesser für die Marschrichtung einer Entwicklung. Neueinsteiger in ein Projekt haben durch die Architektur und ihre ständige Prüfung eine nicht zu unterschätzende Unterstützung bei der Einarbeitung. Änderungen an der Architektur werden in das Bewusstsein der Entwickler gerückt und passieren nicht mehr zufällig sondern zielgerichtet.

Eine Architektur soll kein starres Korsett sein, sondern eine flexible Hilfe bei der Entwicklung: Erweist sich die spezifizierte Architektur als nicht ausreichend, so kann sie jederzeit erweitert werden. Insofern ist bei gefundenen Verstößen immer die Frage erlaubt, ob nicht eigentlich neue Komponenten und Beziehungen in die Architektur aufgenommen gehören.

Woher kommt die Architekturbeschreibung?

Wie kann man eine Architekturprüfung durchführen, wenn gar keine Architekturbeschreibung als Modell vorliegt? Mit einem iterativen, hypothesengetriebenen Ansatz kann eine Architektur schnell wiedergewonnen werden. Sich über die grundsätzliche Architektur einer Software im Team Gedanken zu machen, ist eine wertvolle Erfahrung. Wenn sich ein Entwicklerteam zusammensetzt und einen Tag lang über dieses Thema diskutiert, werden Widersprüche und implizite Annahmen offenbar. Gehen Teammitglieder von unterschiedlichen Annahmen aus, so manifestieren sich diese auch im Code.

Das Reflexionsmodell, das wir oben für eine Prüfung eingesetzt haben, lässt sich auch nutzen, um mit der Architektur zu experimentieren: Eine hypothetische Architektur wird aufgestellt, danach geprüft. Das Wissen über die Abweichungen zwischen Realität im Code und der Hypothese kann dann in der nächsten Iteration in die Anpassung der Hypothese einfließen. Man ist nicht mehr auf bloße Vermutungen angewiesen, sondern kann die Ideen des Teams direkt mit dem Code abgleichen.

Dies erlaubt es, sich langsam seiner Architekturbeschreibung anzunähern. Außerdem sind partielle Beschreibungen möglich, so dass zum Beispiel top down mit einer Grobarchitektur aus wenigen Komponenten begonnen werden kann. Nach Bedarf lassen sich Details hinzufügen. Andererseits lassen sich auch Details spezifizieren, ohne eine Gesamtarchitektur beschreiben zu müssen. Die Wahl der Vorgehensweise hängt sehr stark davon ab, wie viel Zeit man sich nehmen kann und welchen Zweck man verfolgt.

*Dipl.-Inf. Thomas Eisenbarth ist Geschäftsführer der Axivion GmbH. Axivion ist eine Ausgründung aus der Universität Stuttgart, Institut für Softwaretechnologie. Das Unternehmen ist spezialisiert auf die Themen Software-Wartbarkeit und Reverse Engineering und bietet Tools für die statische Codeanalyse sowie Schulungen und Coaching. Kontakt: eisenbarth@axivion.com

 

So lässt sich innere Softwarequalität sicherstellen

 

Was bedeutet Erosion der Software-Architektur?

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 233636 / Software-Entwurf & Echtzeit-Design)