Suche
Power Tools Woche

Architekturqualitätstools

Eberhard Wolff

Innere Qualität ist für die Softwareentwicklung von zentraler Wichtigkeit. Nur wenn die Qualität stimmt, kann Software langfristig kostengünstig weiterentwickelt werden. Soll beispielsweise eine Codebasis für die Wartung übernommen werden, ist eine richtige Einschätzung der Qualität essenziell. Eigentlich müsste die gesamte Codebasis durch ein Code-Review bewertet werden – das ist aber zu aufwändig. Also muss man Tools nutzen, die einen Eindruck von der Qualität des Codes geben. Noch wichtiger ist eigentlich die Architektur: Aus welchen Elementen ist das System aufgebaut? Gibt es Schichten oder andere Abstraktionen?

Oft gibt es eine Dokumentation, wie das System eigentlich aufgebaut sein soll. Aber sie ist meist nicht vollständig oder wurde bei Änderungen nicht mit angepasst. So bleibt die Frage offen, ob der in der Dokumentation dargestellte Zustand sich so auch wirklich im Code wiederfindet.

Code- und Architektur-Reviews

Für eine effektive Analyse des Codes bieten sich Werkzeuge an, die aus dem Code die Struktur ermitteln. Beispiele sind der Sonargraph oder Structure 101. Im Wesentlichen zeigen diese Werkzeuge einen Überblick über die Klassen und Packages der Anwendung und die Beziehungen dazwischen. So lässt sich leicht überprüfen, ob eine Schichtung in der Anwendung auch tatsächlich eingehalten wurde oder ob es Klassen und Packages gibt, die zu groß und komplex sind. Oft ist es erhellend, das Ergebnis einer solchen Analyse mit dem eigentlich angestrebten Bild zu vergleichen, um so die Umsetzung der Architektur zu überprüfen. Außerdem können so architekturelle Probleme wie zyklische Abhängigkeiten erkannt werden. Dass Packages voneinander abhängen, ist natürlich nichts Ungewöhnliches. Bei einer zyklischen Abhängigkeit hängen aber zwei Packages wechselseitig voneinander ab. Wenn also Änderungen in einem der Packages vorgenommen werden, so kann das Auswirkungen auf das jeweils andere Package haben. Die beiden Packages können also streng genommen nicht mehr getrennt entwickelt werden – obwohl sie ja ursprünglich einmal separiert wurden. Genau solche Probleme können mit diesen Tools erkannt werden. Abbildung 1 zeigt einen Package-Zyklus aus einer älteren Versions eines populären Open-Source-Projekts. Ohne den Einsatz dieser Werkzeuge schleichen sich diese Probleme leicht in eine Codebasis ein.

Abb. 1: Überblick über die Struktur einer Anwendung mit Structure 101: Die Packages sind zyklisch voneinander abhängig

Auch sonst helfen die Werkzeuge, weitere Probleme zu identifizieren. So können große und komplexe Packages, Klassen oder Methoden identifiziert werden, bei denen ein genaueres Code-Review sinnvoll sein kann. So kann dieser Schritt sich auf die Teile konzentrieren, die wahrscheinlich besonders problematisch sein werden. Allerdings gibt es in diesem Kontext auch ein Problem: Wie können die Architektur und das System in der Qualität verbessert werden? Structure 101 wie auch Sotograph bieten die Möglichkeit, eine Architektur zu definieren. Eine solche Architektur legt fest, welche Beziehungen zwischen den Packages und Klassen erlaubt sind. Beispielsweis kann so eine Schichtung definiert werden. Dann untersucht das Werkzeug, ob Abhängigkeiten sich tatsächlich an diese Regeln halten. Ist da nicht der Fall, gibt es entsprechende Fehler.

Architektur verbessern

Für eine existierende Codebasis ergibt sich dennoch ein Problem: Die Beziehungen zwischen den Packages und Klassen können so viele Verstöße gegen die Architektur haben, dass die notwendigen Maßnahmen sehr umfangreich werden. Außerdem ist es schwierig, eine Zielarchitektur zu definieren, die zum einen nicht zu komplex umzusetzen ist und zum anderen auch eine sinnvolle Weiterentwicklung ermöglicht. An dieser Stelle lohnt sich ein Blick auf Restructure 101. Dieses Werkzeug stellt die Abhängigkeiten etwas anders da. Abbildung 2 zeigt Restructures Darstellung des Codes aus Abbildung 1. Elemente wie Klassen oder Packages, die in der Grafik weiter oben stehen, haben Abhängigkeiten auf die Elemente darunter. Die konkreten Abhängigkeiten werden nur gezeigt, wenn der Nutzer die entsprechende Option wählt. Dadurch sind die Graphen übersichtlicher. Bei zyklischen Abhängigkeiten ist eine solche Aufteilung natürlich nicht möglich. Daher werden dann die Abhängigkeiten eingezeichnet, die der Von-oben-nach-unten-Konvention widersprechen.

Abb. 2: Die gleiche Situation mit Restructure 101: Nur die Abhängigkeiten in die „falsche“ Richtung werden gezeigt und es werden auch Klassen angezeigt

Dadurch sind die Graphen kompakter. Außerdem ist klar, um welche Abhängigkeiten sich der Entwickler kümmern muss, wenn er die Qualität der Anwendung verbessern will. Restructure 101 hat noch einige andere interessante Aspekte. Wenn in einem Package beispielsweise einige Klassen voneinander abhängen, aber nicht von dem Rest der Klassen in dem Package, so werden diese unterschiedlichen Gruppen entsprechend dargestellt. Eigentlich ist die Struktur des Packages in der Situation falsch gewählt, denn ein Package soll ja eine Gruppe zusammenhängender Klassen enthalten. Der Entwickler kann dann entscheiden, ob er diese Gruppen in eigene Packages heraussepariert. Dazu kann Restructure 101 die Änderungen an der Codebasis simulieren und auch später als Aufgabenliste exportieren.

JAX Innovation Award

Wir gratulieren Restructure 101 zum JAX Innovation Award 2012! Das Tool gewann in San Francisco im Rahmen der JAX US den Award für die „Most Innovative Java Technology“. Letztes Jahr ging dieser Award übrigens an JRebel.

Dieser Aspekt macht Restructure 101 besonders wertvoll: Es weist nicht nur auf die Probleme der Codestruktur hin, sondern bietet auch die Möglichkeit, die Strukturen aktiv zu verbessern. Dabei werden vor allem Packages erzeugt oder Klassen verschoben, was in modernen IDEs automatisiert möglich ist. Dadurch ist das Risiko der Änderungen verhältnismäßig gering, da kaum manuelle Änderungen notwendig sind. Restructure 101 erlaubt es auch, Abhängigkeiten zu markieren, die später durch Codeänderungen entfernt werden müssen, wenn die automatisierbaren Umstrukturierungen nicht ausreichend sind.

Fazit

Mit den vorgestellten Werkzeugen können Projekte recht schnell bewertet werden. Das erleichtert die Arbeit bei einem Code-Review erheblich. Mit Restructure 101 ist eine Verbesserung eines existierenden Systems ohne allzu großen Aufwand machbar. Besonders vorteilhaft ist die grafische Darstellung: Sie ist kompakt und bietet daher einen guten Überblick auch bei komplexen Projekten. Außerdem macht sie das Optimierungspotenzial unter bestimmten Bedingungen sehr offensichtlich.

Eberhard Wolff (Twitter: @ewolff) arbeitet als Architecture and Technology Manager für die adesso AG in Berlin. Er ist Java Champion, Autor einiger Fachbücher und regelmäßiger Sprecher auf verschiedenen Konferenzen. Sein Fokus liegt auf Java und Cloud-Technologien.
Geschrieben von
Eberhard Wolff
Kommentare

Schreibe einen Kommentar

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