2009-06-24 1 views
4

Какие инструменты статического анализа для Java имеют самый простой механизм расширения. Я проверил PMD Но процесс написания пользовательских правил, похоже, очень востребован. В частности, я хочу знать, есть ли какие-либо инструменты, которые предлагают AspectJ как синтаксис для выделения интересных областей кода? Я знаю AspectJ's declare warning, но, похоже, он ограничен в том, что он может сделать.Какой инструмент статического анализа для Java проще всего расширить?

Я нашел связанный с этим вопрос:

рекомендация инструмент статического анализа для Java? Static Analysis tool recommendation for Java?

В ответах на множество инструментов. Но я хочу найти, какой из них предлагает самый простой вариант для написания пользовательских правил.

Редактировать: Пока что выражения PMath XPD, предложенные Гийомом, по-видимому, ближе всего к тому, что я ищу. Я буду изучать его в ближайшее время.

ответ

4

Реальная проблема с «расширением» инструмент статического анализа «статический анализ »- такая широкая тема, что вам нужно много механизмов, чтобы сделать это в целом: синтаксический анализ, построение дерева, извлечение графа потока управления, извлечение потока данных, анализ точек, межпроцедурный анализ, анализ диапазона, список можно продолжать и продолжать , см. тонны компиляторной литературы по анализу программ.

Вы можете использовать поиск по шаблону синтаксиса поверхности сосредоточить внимание инструмента на какой-то программный код, но вы все равно придется объяснить инструмент, что вы хотите, чтобы «статически анализировать» на тот момент (и некоторые анализы [такие как точки-к] требуют, чтобы вы проводили анализ везде , а затем просто выберите нужную часть).

Моральный: не ожидайте, что инструмент будет делать произвольный анализ, чтобы быть легким. Вы должны в основном решить, какие виды анализа вам интересны заранее (tainted input? Subscript range проверяет? API-интерфейс?) И найти инструмент, который уже поддерживает такие вещи. По крайней мере, у ваших «расширений» есть шанс быть простым в силу того, что он похож на то, что уже делает инструмент.

Наш инструментарий DMS Software Reengineering Toolkit - это попытка амортизировать затраты на строительство всех видов анализаторов во многих приложениях и языках. Он обеспечивает анализ синтаксического анализа, управления/потока данных и анализ точек в различной степени для C, C++, Java и COBOL.И у него есть синтаксис поверхности , который поможет вам «указать». См. http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html

+1

Спасибо. DMS Toolkit выглядит довольно интересно. –

1

Дать Findbugs Пользовательский детектор quite simple.

Вы просто заносите его в каталог плагинов вашей установки FindBugs, например, объясните here.

+0

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

+1

Я записал свой опыт, добавив детектор здесь: http://dschneller.blogspot.com/2007/04/findbugs-writing-custom-detectors-part.html –

5

На самом деле довольно легко написать пользовательские правила для PMD. PMD предоставляет синтаксис, похожий на xPath, чтобы найти интересную область вашего кода, поэтому, если у вас есть минимальный опыт работы с XML, вы сможете начать работу в кратчайшие сроки. Я предлагаю вам инвестировать 1-2 часа в PMD или Findbugs и вернуться сюда, если у вас есть конкретные вопросы.

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

+0

Хорошо, я видел стиль АСТ-посетителя для написания правил PMD , Стиль XPath выглядит лучше из-за его декларативного характера. Определенно посмотрим. Thanks –

Смежные вопросы