Czy istnieje narzędzie do wizualizacji, które może sprawdzać bazę kodu Java i raportować zależności między pakietami?

Question

Mamy bazę kodu Java, która stała się zbyt duża dla pojedynczego monolitycznego JAR (ponad 5000 klas). Jednym z zadań, które badamy, jest to, ile wysiłku byłoby rozbicie tego pojedynczego pliku JAR na mniejsze komponenty z kontrolowanymi zależnościami między nimi. Jednak trochę trudno jest spojrzeć na dużą torebkę kodu i upewnić się, że znajdujesz najlepsze punkty separacji bez jakiejkolwiek analizy.

Czy istnieją dobre narzędzia do sprawdzania i wizualizacji zależności interpackażu? Biorąc to pod uwagę, mielibyśmy zestaw sugerowanych punktów cięcia, w których moglibyśmy rozpocząć oddzielanie kodu.

Jako przykład, w dniach przed Netbeans i Eclipse (i przy innej pracy) użyliśmy TogetherJ i TogetherEnterprise. Ci mieli możliwość wykonania statycznej analizy pakietów i narysowania diagramu UML. Takie zachowanie byłoby optymalne, ale ta funkcja sama w sobie nie wystarcza, aby uzasadnić koszt.

Answer 1

SonarJ to dobre narzędzie do tego, ale jest drogie.

Innym bardzo dobrym narzędziem jest XDepend, które jest tańsze. W twoim przypadku poleciłbym ci to narzędzie. Najlepszy wybór pod względem jakości/ceny, myślę.

Przy znacznie mniejszej liczbie funkcji można użyć analizy Sonar (Free i OpenSource) oraz jej macierzy zależności.

Answer 2

Czy zajęcia korzystają z pakietów w normalny sposób lub czy wszystkie klasy są w tym samym pakiecie? Jeśli pierwszy przypadek jest prawdziwy, rozważę napisanie specjalnego narzędzia do wykonania pierwszego cięcia.

Answer 3

W tym samym celu użyłem stan4j, ale niestety edycja społecznościowa ma limit 500 klas. Z drugiej strony działa jako rozszerzenie zaćmienia.

Answer 4

Niedawno odkryto CodePro AnalytiX, dawniej z dawałaby, teraz dostępny za darmo od Google: https://developers.google.com/java-dev-tools/codepro/doc/features/dependencies/dependencies

Answer 5

Intellij IDEA ma jedno:

alt text http://www.jetbrains.com/idea/features/screenshots/70/dsm/dsmView2.gif

Answer 6

JDepend to darmowe narzędzie do analizowania zależności pakietów .

Identyfikuje okrężne zależności, które utrudniłyby rozbicie tego monolitu na mniejsze kawałki.

Ten test sprawdzamy pod kątem zależności kołowych w naszych testach jednostkowych, aby zapobiec ich uruchomieniu.

Istnieje odpowiednia Eclipse plug-in.

Możesz wysłać dane wyjściowe do GraphViz. Wizualizacja staje się jednak mniej zrozumiała, ponieważ liczba pakietów rośnie.

Teraz, gdy CodePro AnalytiX [wspomniany wcześniej przez Fabiana Steega powyżej] jest bezpłatny, warto spojrzeć jeszcze raz. Przynajmniej przed zakupem przez Google Instantiations niezawodnie tworzyło świetne oprogramowanie. Grałem z nim kilka lat temu i nie odwołuję się do żadnych skarg poza kosztami.

Answer 7

Dobrą próbą byłoby odwrócenie pliku JAR na diagram klas.Znalazłem ten samouczek, który wyjaśnia, jak odwrócić projekt złożony z plików JAR na diagram klasowy UML: http://www.ejb3.org/jar_file_reverse/jar_file_reverse.html

Będziesz mógł cofać się na poziomie pakietu, zobacz relację w pakiecie, ale także zobacz klasesy z jednej paczki mającej związek z innymi pakiety. Po wycofaniu projektu można go zreorganizować jako model i przekazać tę dokumentację zespołowi wdrożeniowemu.

Answer 8

Jest to dokładnie ten rodzaj przypadku użycia buduję degraph dla.

Umożliwia definiowanie plasterków , tj. Zestawów klas, które należą do siebie i wizualizuje je jako jeden zwijany węzeł. Twoje słoiki to plasterki, które możesz modyfikować, dopóki nie będą miały żadnych cyklicznych zależności, w którym to momencie mogą stać się ich własnymi słojami.

Ułatwia to wykrycie zależności między plasterkami, które należy złamać. Ponieważ możesz otworzyć węzeł przekroju i zobaczyć wszystkie zawarte klasy, to również łatwo jest zidentyfikować możliwe refaktoryzacje (wprowadzenie interfejsów, przeniesienie klas ..), aby osiągnąć cel.