Существует ли инструмент визуализации, который может проверять базу кода Java и сообщать о зависимостях между пакетами?

У нас есть кодовая база Java, которая стала слишком большой для одного монолитного JAR (более 5000 классов). Одна из задач, которую мы исследуем, заключается в том, сколько усилий потребуется, чтобы разбить этот единственный JAR на более мелкие компоненты с контролируемыми зависимостями между ними. Тем не менее, довольно сложно смотреть на большой пакет кода и быть уверенным, что вы найдете лучшие точки разделения без некоторого анализа.

Существуют ли хорошие инструменты для проверки и визуализации зависимостей между пакетами? Учитывая это, у нас был бы набор предлагаемых точек среза, с которых мы могли бы начать разделять код.

Например, за несколько дней до появления Netbeans и Eclipse (и на другой работе) мы использовали TogetherJ и TogetherEnterprise. У них была возможность провести статический анализ пакетов и нарисовать UML-диаграмму. Такое поведение было бы оптимальным, но одной этой функции недостаточно, чтобы оправдать затраты.


dependencies java static-analysis uml packages
person Bob Cross    schedule 29.09.2010    source источник
comment
Я думаю, что если вам нужен инструмент, который расскажет вам, как организовать ваши 5000 занятий, то у вас больше проблем, чем этот инструмент может вас избавить. Удачи.   -  person z5h    schedule 30.09.2010
comment
@z5h, честно? Почему бы вам не использовать инструмент для поиска зависимостей? Вывод такого инструмента очень полезен для проведения работ по рефакторингу. Помните, что это то, что помогает вам идентифицировать узлы со слабой взаимной связью. Затем эти узлы могут стать кандидатами для отдельных поставляемых продуктов сборки. Более короткое время сборки для обоих, локализованные изменения и т. д. — все это сильные мотивы для такого рода рефакторинга. Если есть инструменты, которые помогают указать начало здесь, этот разрез будет легким, почему бы вам не использовать такую ​​​​вещь?   -  person Bob Cross    schedule 30.09.2010
comment
Я просто заметил, что если вы находитесь на этапе, когда у вас есть 5000 классов, а архитектуры приложения недостаточно, чтобы вести вас в правильном направлении без инструмента, то это звучит как очень плохая ситуация. Это не упражнение по оптимизации, когда инструмент говорит вам, на что смотреть дальше. Это вся архитектура вашего приложения, с которой лучше разобраться. Если вы используете этот инструмент для проверки идей, то это звучит хорошо. Если он ведет ваш дизайн, это звучит пугающе. Вы сказали, что инструмент будет руководить вашим дизайном.   -  person z5h    schedule 30.09.2010
comment
@z5h, нет, код — это не архитектура. Код — это реализация. Архитектура может нарисовать прямоугольники линиями и сказать, что это задуманный дизайн. Инструмент проверки может просмотреть код и убедиться, что ни одно из полей на диаграмме архитектуры не имеет скрытого соединения, хотя этого не должно быть. Например, случайное остаточное включение может привести к зависимости между двумя фрагментами кода, которые никогда не должны были быть связаны, но теперь имеют скрытую ложную зависимость, влияющую на порядок сборки. Инструмент может проверить ваш код, чтобы убедиться, что он соответствует архитектуре.   -  person Bob Cross    schedule 30.09.2010

Ответы (8)


arrow_upward
3
arrow_downward

Недавно я обнаружил CodePro AnalytiX, ранее принадлежавший Instantiations, теперь доступный бесплатно в Google: https://developers.google.com/java-dev-tools/codepro/doc/features/dependencies/dependencies

person Fabian Steeg    schedule 29.09.2010

arrow_upward
2
arrow_downward

Я использовал stan4j для той же цели, но, к сожалению, версия для сообщества имеет ограничение в 500 классов. С другой стороны, он работает как расширение затмения.

person andcoz    schedule 29.09.2010

arrow_upward
2
arrow_downward

Intellij IDEA имеет один:

alt text
(источник: jetbrains.com)

person OscarRyz    schedule 29.09.2010

arrow_upward
1
arrow_downward

JDepend — это бесплатный инструмент для анализа зависимостей пакетов.

Он выявляет циклические зависимости, которые мешают разбить этот монолит на более мелкие части.

Мы помещаем эту проверку циклических зависимостей в наши модульные тесты, чтобы предотвратить их с самого начала.

Существует соответствующий подключаемый модуль Eclipse.

Вы можете отправить вывод в GraphViz. Однако визуализация становится менее понятной по мере роста количества пакетов.

Теперь, когда CodePro AnalytiX [упомянутый выше Фабианом Стигом] является бесплатным, стоит еще раз взглянуть на него. По крайней мере, до покупки Google Instantiations надежно производила отличное программное обеспечение. Я играл с ним несколько лет назад и не помню никаких жалоб, кроме стоимости.

person Andy Thomas    schedule 29.09.2010

arrow_upward
1
arrow_downward

Хорошей попыткой было бы преобразовать файл jar в диаграмму классов. Я нашел этот учебник, в котором объясняется, как преобразовать проект, составленный из файлов jar, в диаграмму классов UML: http://www.ejb3.org/jar_file_reverse/jar_file_reverse.html

Вы сможете выполнить реверсирование на уровне пакета, просмотрев отношение пакета, а также увидеть классы из одного пакета, имеющие отношение к другим пакетам. После реверсирования проекта вы можете преобразовать его в модель и передать эту документацию группе реализации.

альтернативный текст

person UML GURU    schedule 30.09.2010

arrow_upward
1
arrow_downward

SonarJ — хороший инструмент для этого, но он дорогой.

Еще одним очень хорошим инструментом является XDepend, который дешевле. Для вашей цели, я бы порекомендовал вам этот инструмент. На мой взгляд лучший выбор по соотношению цена/качество.

С гораздо меньшими функциональными возможностями вы можете использовать анализ Sonar (бесплатный и с открытым исходным кодом) и его матрицу зависимостей.

person Benoit Courtine    schedule 29.09.2010

arrow_upward
0
arrow_downward

Используют ли классы пакеты обычным образом или все классы находятся в одном пакете? Если первый случай верен, я бы подумал о написании специального инструмента для выполнения первого разреза.

person Tony Ennis    schedule 29.09.2010
comment
оригинальная архитектура изложила вещи разумным образом. Однако годы запросов клиентов и новых разработок привели к годам правок, и пришло время собрать все это вместе. 5000 занятий в одном пакете было бы отвратительно, не так ли? - person Bob Cross; 01.10.2010
comment
@bob cross - да, действительно. Я думаю, что мне придется поиграть с ним некоторое время, чтобы определить, как действовать дальше. - person Tony Ennis; 01.10.2010

arrow_upward
0
arrow_downward

Это именно тот вариант использования, для которого я создаю degraph.

Он позволяет вам определять срезы, то есть наборы классов, которые принадлежат друг другу, и визуализировать их как один сворачиваемый узел. Ваши jar-файлы должны быть фрагментами, которые вы можете настраивать до тех пор, пока у них больше не будет циклических зависимостей, после чего они могут стать их собственными jar-файлами.

Это упрощает обнаружение зависимостей между фрагментами, которые необходимо разорвать. Поскольку вы можете открыть узел среза и увидеть все содержащиеся в нем классы, это также упрощает определение возможных рефакторингов (введение интерфейсов, перемещение классов и т. д.) для достижения вашей цели.

person Jens Schauder    schedule 17.03.2013