Gibt es ein Visualisierungstool, mit dem eine Java-Codebasis untersucht und Abhängigkeiten zwischen den Paketen gemeldet werden können?
Wir haben eine Java-Code-Basis, die für ein einzelnes monolithisches JAR (mehr als 5000 Klassen) zu groß geworden ist. Eine der Aufgaben, die wir untersuchen, ist, wie viel Aufwand es wäre, diese einzelne JAR in kleinere Komponenten mit kontrollierten Abhängigkeiten zwischen ihnen zu brechen. Es ist jedoch etwas schwierig, sich einen großen Code anzusehen und sicher zu sein, dass Sie die besten Trennungspunkte ohne eine Analyse finden.
Gibt es gute Werkzeuge, um die Interpackage-Abhängigkeiten zu überprüfen und zu visualisieren? Unter diesen Umständen hätten wir eine Reihe von empfohlenen Schnittpunkten, wo wir anfangen könnten, den Code zu trennen.
Als Beispiel haben wir in den Tagen vor Netbeans und Eclipse (und bei einem anderen Job) TogetherJ und TogetherEnterprise verwendet. Diese hatten die Fähigkeit, eine statische Paketanalyse durchzuführen und das UML-Diagramm zu zeichnen. Diese Art von Verhalten wäre optimal, aber diese Eigenschaft allein reicht nicht aus, um die Kosten zu rechtfertigen.
8 Antworten
Ich habe kürzlich CodePro AnalytiX, früher von Instantiations, entdeckt, die jetzt kostenlos bei Google erhältlich sind: Ссылка
JDepend ist ein kostenloses Tool zur Analyse von Paketabhängigkeiten.
Es identifiziert kreisförmige Abhängigkeiten, die den Bruch dieses Monolithen in kleinere Stücke verhindern würden.
Wir setzen diese Überprüfung auf zirkuläre Abhängigkeiten in unsere Unit-Tests ein, um sie von Anfang an zu verhindern.
Es gibt ein entsprechendes Eclipse-Plug-In .
Sie können die Ausgabe an GraphViz senden. Die Visualisierung wird jedoch weniger verständlich, wenn die Anzahl der Pakete zunimmt.
Nun, da CodePro AnalytiX [das zuerst von Fabian Steeg oben erwähnt wurde] kostenlos ist, ist es einen anderen Blick wert. Zumindest vor dem Kauf von Google, Instantiations produziert zuverlässig großartige Software. Ich habe vor ein paar Jahren damit gespielt und mich nur an die Kosten erinnert.
Ein guter Versuch wäre, Ihre JAR-Datei in ein Klassendiagramm umzukehren. Ich habe dieses Tutorial gefunden, das erklärt, wie man ein Projekt, das aus JAR-Dateien besteht, in ein UML-Klassendiagramm umwandelt: Ссылка
Sie können auf der Paketebene umkehren, um die Paketbeziehung zu sehen, aber auch, um die Klassen aus einem Paket mit Relationen zu anderen Paketen zu sehen. Sobald das Projekt umgekehrt wurde, können Sie es als Modell reorganisieren und diese Dokumentation dem Implementierungsteam zur Verfügung stellen.
SonarJ ist ein gutes Werkzeug, um das zu tun, aber es ist teuer.
Ein weiteres sehr gutes Tool ist XDepend , das ist billiger. Für Ihren Zweck würde ich Ihnen dieses Tool empfehlen. Die beste Wahl in Bezug auf Qualität / Preis denke ich.
Mit viel weniger Funktionen können Sie eine Sonar (Freie und OpenSource) -Analyse und ihre Abhängigkeiten-Matrix verwenden.
Verwenden die Klassen Pakete auf normale Weise oder sind alle Klassen im selben Paket? Wenn der erste Fall wahr ist, würde ich überlegen, ein Spezialwerkzeug zu schreiben, um den ersten Schnitt zu machen.
Dies ist genau die Art von Anwendungsfall, den ich für degraph erstelle.
Sie können Slices definieren, d. h. Gruppen von Klassen, die zusammengehören, und sie als einen zusammenklappbaren Knoten visualisieren. Sie sollten Slices sein, die Sie optimieren können, bis sie keine zyklischen Abhängigkeiten mehr haben. An diesem Punkt können sie zu einem eigenen Jar werden.
Dies macht es einfach, Abhängigkeiten zwischen Slices zu erkennen, die Sie unterbrechen müssen. Da Sie den Slice-Knoten öffnen und alle enthaltenen Klassen sehen können, ist es auch leicht möglich, mögliche Refactorings (Einführung von Interfaces, Moving-Klassen ...) zu identifizieren, um Ihr Ziel zu erreichen.
Tags und Links dependencies java packages uml static-analysis