Irgendwie spuckt jDepend interessante Werte aus, aber was so richtig damit anfangen? Nur eine Zahl um so etwas wie Paket-Instabilität auszudrücken? Wieso soll ich mich überhaupt um zyklische Abhängigkeiten kümmern, wenn mein System doch prima läuft? Und was um alles in der Welt ist ein dot in der Graphenvisualisierung?

Ok, fangen wir mal ganz einfach an. Als erstes zählt jDepend⁽¹⁾ ein paar ganz einfache Dinge, wie z.B. alle Klassen (NoC). Dabei wird zwischen der Anzahl abstrakter (NoAC) und konkreter Klassen (NoCC) unterschieden. Allein daraus kann der Wert für Abstractness (A = NoAC/NoC) ermittelt werden. Ja und, was sagt mir das? Erstmal noch nicht viel. Verdächtig sind eventuell Systeme die kaum Abstraktion verwenden, nicht nur weil Abstraktion das geeignete Mittel der Wahl ist wartungsunfreundliche Labyrinthmethoden⁽²⁾ oder komplizierte If-Then Konstrukte⁽³⁾ zu lösen, um auf diese Weise die zyklomatische Komplexität⁽⁴⁾ zu verringern oder eben den richtigen Schnitt bei den Verantwortlichkeiten der Klassen und Pakete zu finden.

Der nächste Bereich sind die Paket-Abhängigkeiten. Da unterscheidet jDepend zwischen eingehende Abhängigkeiten, sog. Afferent Coupling (Ca) und ausgehende Abhängigkeiten, sog. Efferent Couplings (Ce). Ca meint die Anzahl von “entfernte” Paketen, die Klassen des zu zählenden Paketes verwenden. Bei Ce ist es umgekehrt. Da werden die Pakete gezählt, von denen das aktuelle Paket “entfernte” Klassen verwendet.
Ein wichtiger Nebeneffekt ist dabei die Feststellung von zyklischen Abhängigkeiten. Wenn Paket A Paket B braucht aber auch in Paket B Klassen von Paket A verwendet werden, ist irgendetwas faul. Das sollte bei einem halbwegs ausgewogenem System nicht vorkommen, oder zu mindestens einen wirklich triftigen Grund haben. Der Schnitt der Pakete ist bei zyklischen Abhängigkeiten in der Regel so einfach nicht wirklich sinnvoll, nicht nur für die normale Wartung.
Und wenn wir schon ein System bezüglich seiner Abhängigkeiten auseinander nehmen, können wir doch die Abhängigkeiten mit wenig Aufwand in einen Graphen darstellen. Und wer sich schonmal mit Visualisierung von Graphen beschäftigt hat, der wird schonmal mit dem Dot⁽⁵⁾ des GraphViz-Tool in Berührung gekommen sein. So sieht also eine Dependency-Visualisierung eines kleinen Software-System⁽⁶⁾ mit GraphViz/dot aus (Klick for Big):

Hier das ganze auch als SVG.

Soweit also erstmal die Basiszählereien. Als nächstes rechnet jDepend die Zahlen zu zwei weiteren wirklich interessanten Werten zusammen. Ad eins wird ein Wert für Instabilität (I) ermittelt. Der ist einfach zu erklären. Es ist einfach das Verhältnis von ausgehender Abhängigkeit (Ce) zu der Gesamtanzahl der Abhängigkeiten also (I = Ce / (Ce + Ca)).
Die letze Zahl im jDepend-Reigen nennt Mr. Clark⁽⁷⁾ einfach semantikfrei Distance (D). Gemeint ist hier die Distanz von der Optimallinie. Die Optimallinie ist die Diagonale, die zwischen einem absolut abstrakten und stabilen (0,0) und einem 100% konkreten und absolut instabilen (1,1) Paket gespannt ist. Für’s Management: Umso kleiner, umso feiner. Hier stimmt also der Satz “Size Matters” aber mal so richtig richtig. Und: es kommt eben doch auf die richtige Technik an *g*.

Übrigens wer das Thema der Paket-Abhängigkeiten bis zum letzten ausreizen möchte, um ausgewogene, nachhaltige Systeme zu bauen, sollte sich evt. mal das ($)-Tool Lattix⁽⁸⁾ anschauen. Damit lassen sich nicht nur prima Systeme auf Paket-Ebene refaktorisieren, sondern auch komplexe Architekturen managen. Etwas einfacher als Lattix ist der JarAnalyzer⁽⁹⁾, welcher die selbe Struktur wie JDepend bietet, aber das Ganze auf JAR-Ebene betrachtet. Er beantwortet somit u.a. die Frage, welche JAR’s brauche ich, evt. sogar in welcher Version, damit mein System funktioniert. Während der JarAnalyzer über JDepend zielt, fixiert sicht das Tool ckjm⁽¹⁰⁾ auf ein’s unter den Paketen, nämlich auf die Klassen-Beziehungen. Übrigens, ckjm ist vom guten Herrn Spinellis⁽¹¹⁾ geschrieben worden, der z.B. auch für das doclet-basierte UML-Tool UMLGraph verantwortlich zeitigt. Dazu hatte ich im Javamagazin⁽¹²⁾ ja schonmal was zu geschrieben.

+++

(1) = jDepend Homepage
(2) = Labyrinth-Methode ist ein AntiPattern nicht nur nach bei Sissy.
(3) = Refactoring nach Fowler
(4) = Zyklomatische Komplexität nach McCabe
(5) = GraphViz erzeigt .dot-Files.
(6) = Gaby’s Rezepte: Ein feines Tool um Kochrezepte zu verwalten.
(7) = Mik Clark Blog bei Clarkware
(8) = Lattix - Software for Architecture Management
(9) = JarAnalyzer Homepage
(10) = ckjm — Chidamber and Kemerer Java Metrics
(11) = Diomidis D. Spinellis Homepage
(12) = Deklarative Modellierung mit UMLGraph, Javamagazin, 03.2005