Java-Code visualisieren: Stadtneurotiker - JAXenter

Java-Code visualisieren: Stadtneurotiker

Wege zur Harmonisierung

Nun stellt sich die Frage, wie solche schlechten Eigenschaften beseitigt werden können. Da der Kosten- als auch Zeitaufwand für entsprechende Analysen und vor allem für die sich anschließenden Maßnahmen sehr hoch ist und in den meisten Fällen nur eine untergeordnete Rolle in der Budgetplanung eines Projekts einnimmt, ist es wichtig, eine geeignete Priorisierung der verschiedenen möglichen Refaktorisierungen vorzunehmen. Hierbei ist zu beachten, dass Entwurfsdisharmonien nicht immer behoben werden müssen. Eine technische Utility-Klasse, die den Geruch der Brain-Class-Disharmonie verbreitet aber kein fachliches Verhalten beinhaltet und/oder beeinflusst ist normalerweise kein Kandidat für eine Entwurfsrefaktorisierung [1].

Unter Berücksichtigung dieser Feststellung und Beachtung des gesunden Menschenverstands beginnen wir mit einer Analyse der Klassen des Projekts, in denen sich die Intelligenz bündelt, also den God und Brain Classes. Ziel der Untersuchung ist es, dort diejenigen Methoden zu finden, die:

  • duplizierten Code enthalten
  • auf viele Attribute anderer Klassen zugreifen (Feature Envy) und/oder
  • Brain Methods sind

Haben wir die Methoden identifiziert, entfernen wir den gegebenenfalls vorhandenen doppelten Code durch geeignete Refaktorisierungen wie Extract Method [5].

Bevor wir uns nun den Zugriffen auf Attribute anderer Klassen widmen, sollten wir alle Temporary Fields [5] finden. Diese sind Attribute einer Klasse, die nur in einer Methode verwendet werden. Sie verfälschen die Metrik zur Kohäsion, indem sie diese verringern und das Auftreten der Entwurfsdisharmonien God und Brain Class fördern. Daher sollten die temporären Felder durch lokale Variablen ersetzt und danach erneut ermittelt werden, ob die beiden Entwurfsdisharmonien noch bestehen.

Nun können wir den Zugriff auf zahlreiche Attribute anderer Klassen entfernen, indem wir die in Abbildung 4 dargestellten Refaktorisierungen durchführen. Im Fall von Feature Envy sind nur die Attribute sehr weniger Fremdklassen (Literaturwert: 1 bis 2) betroffen [1]. Daher kann allein die Verschiebung der Methode schon Linderung bringen.

Abb. 4: Refaktorisierungen für die Entwurfsdisharmonien Feature Envy und Data Class (Auszug aus [1])Abb. 4: Refaktorisierungen für die Entwurfsdisharmonien Feature Envy und Data Class (Auszug aus [1]) (Vergrößern)

Sollte nach diesen Anpassungen die Disharmonie Brain Method weiterhin bestehen, können deren negativen Eigenschaften durch weiteres Extrahieren des Codes in separate Methoden behoben werden. Im Fall der Shotgun-Surgery-Disharmonie empfiehlt es sich zu prüfen, ob das Verhalten der Klienten dieser Methode der Shotgun-Surgery-Klasse zugeordnet werden kann.

Vom Java-Code zur Code City
Installation von inFusion und CodeCity

Um ein Stadtbild unseres Java-Projekts erhalten zu können, müssen wir zwei Anwendungen aus dem Internet herunterladen und extrahieren: inFusion [6] und CodeCity [7].

Metrikbasierte Analyse mit inFusion 7.2

Die von CodeCity zu visualisierenden Metriken werden mittels inFusion gesammelt und für CodeCity exportiert. Dazu starten wir inFusion durch Ausführung von infusion.bat (Windows) oder infusion.sh (Mac, Linux, Unix) und klicken rechts oben auf den Button LOAD NEW PROJECT… Dort laden wir das zu analysierende Java-Projekt nach Auswahl seines Sourcecode Verzeichnisses. Im unteren Panel navigieren wir anschließend nach einem Rechtsklick auf das Sourcecode Verzeichnis über RUN TOOL… zu FAMIX 2.1 MSE EXPORTER und speichern dort die Metrikendatei unter einem Namen mit der Dateiendung mse (Moose).

Der Code als Stadt mit CodeCity 1.4

Nun können wir CodeCity durch Aufruf von codecity.exe (Windows) oder codecity-x11.app (Mac) starten und im Fenster CODECITY die Metrikendatei durch Klick auf den Button AN MSE FILE… öffnen, der sich im Abschnitt IMPORT MODEL(S) FROM befindet. Danach wählen wir das zu untersuchende Projekt in der Tabelle aus, klicken auf den Button CITY und erhalten ein Stadtbild des Codes.

Anzeige von Disharmonien

Disharmonien können wir durch Klick auf das Radioaktivitäts-Icon (OPEN DISHARMONY MAP) auswählen und anzeigen lassen.

Navigation

Wenn wir den Mauszeiger über die Artefakte der Code City schweben lassen, erfahren wir im rechten Informationspanel, um welche Klasse oder welches Package es sich handelt und wie viele LOC, Methoden und Attribute die Klasse besitzt. Mithilfe der Tastatur können wir die Stadt wie in Tabelle 1 aufgezeigt erkunden.

Weitere Informationen bieten die Video-Tutorials unter [8] oder die Präsentationen über CodeCity [9].

Tabelle 1: Mithilfe der Tastatur die Stadt erkunden

Tasten Aktion
W, S Zoom
A, D Verschiebung entlang der horizontalen Achse
STRG + PFEIL OBEN/UNTEN Rotation um die horizontale Achse
STRG + PFEIL LINKS/RECHTS Rotation um die vertikale Achse
+ SHIFT Aktionen in kleineren Schritten ausführen
Ausblick

Neben den hier erwähnten gibt es noch weitere Disharmonien, z. B. bezüglich des Kopplungsgrades von Klassen. Diese lassen sich jedoch nur zum Teil mittels CodeCity visualisieren. Die Anwendung bietet darüber hinaus noch die Möglichkeit, sich Vererbungs- und Aufrufbeziehungen anzeigen zu lassen.

Ein weiteres sehr interessantes Feature für den praktischen Einsatz ist die Darstellung der zeitlichen Veränderung des Systementwurfs mithilfe von so genannten Age Maps. Hierbei werden, ähnlich wie in Abbildung 3, die Methoden einer Klasse in Form kleiner Würfel dargestellt, deren Farbe das Alter des jeweiligen Codes zum Ausdruck bringt. Gelöschte Methoden hinterlassen Löcher im Gebäude. Hieraus können wir einen Eindruck von der Stabilität der Klasse gewinnen.

Zusammenfassung

Viele Entwickler schlagen sich jeden Tag aufs Neue mit schwergewichtigen, fachlich anspruchsvollen Altsystemen herum. Mithilfe der durch CodeCity visualisierten Disharmonien können sie einen schnellen Überblick über den Entwurfszustand des Systems gewinnen. Eine einfache Rechnung verdeutlicht dies: Das von uns in diesem Artikel verwendete Beispielsystem weist über 188.000 LOC auf. Bei einer Lesegeschwindigkeit von zwei Codezeilen pro Sekunde wären wir über drei Arbeitstage mit der reinen Lektüre beschäftigt, wohlgemerkt ohne die Zusammenhänge verstanden zu haben. CodeCity ermöglichte es uns stattdessen, innerhalb eines Tages die wesentlichen Entwurfsprobleme des Systems zu identifizieren und schon zum Teil nachzuvollziehen.

Bastian Helfert arbeitet als Softwareentwickler und Berater bei der akquinet tech@spree GmbH in Berlin (bastian.helfert[at]akquinet.de).

Steffen Hohn beschäftigt sich als theoretischer Physiker seit längerer Zeit mit der Untersuchung und Visualisierung komplexer Systeme. Er ist als Softwareentwickler und Berater bei der akquinet tech@spree GmbH in Berlin tätig (steffen.hohn[at]akquinet.de).

Kommentare

Schreibe einen Kommentar

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