Softwarequalität: Architekturmodelle und Metriken mit Sonargraph

Jede Software hat eine Architektur!

Niklas Bulitta, Arkadius Czarni, Patrick Lehmann und Thorsten Kamann

Jede Software hat eine Architektur heißt es. Doch wie sieht die Architektur aus und wie kann sie beschrieben werden? Wie lässt sich die Qualität einer Software beurteilen und wie kann sichergestellt werden, dass getroffene Architekturentscheidungen auch eingehalten werden? Am konkreten Beispiel der Webapplikation Softwarekoch wird mittels des Werkzeugs Sonargraph Quality gezeigt, wie sich die Qualität von Software bewerten lässt.

Eine weit verbreitete und allgemein akzeptierte Definition von Softwarearchitektur ist:

The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components and the relationships among them. Bass, Clements und Kazman 1998

Jede Software besitzt eine Architektur. Das ist jedoch nicht immer offensichtlich. Jedes vernünftige Softwareprojekt wird in seiner Entwurfsphase versuchen, eine den Anforderungen entsprechende Softwarearchitektur zu definieren. Die Wahl dieser Architektur hat einen entscheidenden Einfluss auf die Qualität der Software, doch was ist der richtige Maßstab, um sie anschließend zu bewerten? Der Grad der Softwarequalität wird davon bestimmt, inwieweit eine Software den an sie gestellten Anforderungen genügt. Man unterscheidet dabei nichtfunktionale und funktionale Anforderungen. Die Erfüllung letzterer wird durch Software-Testing gemessen und soll hier nicht näher betrachtet werden. Die Erfüllung der nichtfunktionalen Anforderungen wird wesentlich durch die gewählte Struktur, also durch die Architektur bestimmt.

Leider ist es mit der einmaligen Festlegung einer geeigneten Architektur vor dem Beginn der eigentlichen Implementierung nicht getan. Denn zum einen können sich die Anforderungen während der Entwicklung verändern und zum anderen tendiert jede Software dazu, im Verlauf ihrer Weiterentwicklung die vorgesehene Struktur zu verlieren („The software starts to rot“, [1]). In der Regel liegt das daran, dass die umsetzenden Entwickler entweder die vorgegebene Architektur nicht kennen oder sie nicht vollständig verstanden haben. In jeden Fall gibt es für Softwareprojekte den Bedarf, Softwarearchitektur initial zu definieren und deren Einhaltung im Laufe der Entwicklung kontinuierlich zu überprüfen. Der Hersteller hello2morrow des kommerziellen Produktes Sonargraph Quality behauptet, für diese Problemstellung die geeignete Lösung anzubieten. Als Nachfolger der Produkte SonarJ und Sotograph vereint es dessen umfangreiche Möglichkeiten zur statischen Codeanalyse. Wir werden in diesem Artikel seine Fähigkeiten genauer beleuchten, doch zuerst möchten wir auf die Grundlagen der Analyse zu sprechen kommen.

Codequalität und Metriken

Ein Entwickler hat sich noch nicht mit Codequalität auseinander gesetzt. Er erhält den Auftrag, ein bestehendes, ihm unbekanntes Softwaresystem zu analysieren. Bei der Recherche nach den üblichen Möglichkeiten, stößt er auf das Thema Codemetriken. Das sind formale Kennzahlen, die Aussagen über bestimmte Eigenschaften eines Softwaresystems treffen. Diese Eigenschaften können einfach sein, wie z. B. das Zählen der Codezeilen oder komplex, wie die Ermittlung eines Abhängigkeitsgraphen. Metriken helfen uns, einen Gesamteindruck eines Softwaresystems zu gewinnen. So ermittelte Kennzahlen sind objektiv, nachvollziehbar und vergleichbar.

Neben diesen Vorteilen haben Metriken aber auch das Potenzial, dem Projekt zu schaden. Was sagt eine hohe Testabdeckung aus? Für sich allein betrachtet nicht viel, die Abdeckung lässt sich z. B. durch Dummytests manipulieren. Es kann aber auch sein, dass nur sinnlose Stellen getestet wurden wie z. B. getter, setter oder toter Code. Eine Testabdeckung von 0 % sollte allerdings alarmieren. Daher ist es mit Metriken wie beim Würzen eines Eintopfs: die richtige Mischung ist entscheidend und es hilft ganz bestimmt, auch mal selbst zu probieren.

Um Erfahrung zu sammeln und sich mit dem Thema vertraut zu machen, sollten für den Start wenige Metriken gewählt werden. Mit dem Basisset in Tabelle 1 können bereits Aussagen abgeleitet und Optimierungen geplant werden. Allein durch Analyse dieser wenigen Metriken lassen sich bereits Verbesserungsmaßnahmen ableiten, um die Qualität der Software nachhaltig zu verbessern.

Tabelle 1: Metriken und ihre Bedeutung

Metrik Name Bedeutung
#NCSS Number of Non-Comment Source-Statements Eine Zeile NCSS ist eine (nicht leere) Zeile, die kein Kommentar ist. Daher ist #NCSS die Anzahl der „echten“ Quellcodezeilen. Generell sind die #-Metriken nützlich, um anderen Metriken in Bezug auf die Größe der Codebasis zu setzen.
CCN McCabe’s Cyclomatic Complexity Number Gibt die Komplexität einer Methode an. Komplexe Methoden haben in der Regel eine schlechte Testbarkeit und Verständlichkeit.
#packages Number of Java Packages Anzahl der Pakete.
#types Number of Java Types Anzahl an Typen.
LCR Line Coverage Rate Verhältnis von durchlaufenen Codezeilen zu nicht durchlaufenen. Wird zur Messung der Testabdeckung oder zur Identifizierung von totem Code verwendet.
Instability Instability of Classes Sagt etwas über die Modularisierung aus. Klassen und Pakete sollten entweder instabil oder stabil sein. Eine stabile Klasse hat wenig bis keine Abhängigkeiten eine instabile hat hingegen sehr viele Abhängigkeiten.
#in_cycles Cycles Anzahl der gemessenen Zyklen (Zwei voneinander abhängige Artefakte). Zyklen wirken sich negativ auf Verständlichkeit, Erweiterbarkeit, Wartbarkeit und Testbarkeit aus.
Geschrieben von
Niklas Bulitta, Arkadius Czarni, Patrick Lehmann und Thorsten Kamann
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.