Инструмент для проверки моделей больших, распределенных проектов C ++, таких как KDE?

Question

Существует ли инструмент, который может выполнять проверку моделей в больших, реальных, в основном C ++, распределенных системах, таких как KDE?

(KDE - это распределенная система в том смысле, что она использует IPC, хотя обычно все процессы находятся на одной машине. Да, кстати, это допустимое использование «распределенной системы» - см. Википедию.)

Инструмент должен иметь возможность обрабатывать внутрипроцессные события и межпроцессные сообщения.

(Предположим, что если инструмент поддерживает C ++, но не поддерживает другие вещи, которые использует KDE, такие как moc, мы можем взломать что-то вместе, чтобы обойти это.)

Я с радостью приму менее общие (например, статические анализаторы, специализирующиеся на поиске определенных классов ошибок) или более общие статические аналитические альтернативы вместо реальных проверок моделей. Но меня интересуют только инструменты, которые могут на самом деле обрабатывать проекты размером и сложностью KDE.

Answer 1

Вы, очевидно, ищете инструмент статического анализа, который может

• разбирать C ++ по шкале
• найти интересующие фрагменты кода
• извлечь модель
• передать эту модель на проверку модели
• сообщить вам результат

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

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

Поставщики коммерческих инструментов статического анализа кажутся логичным местом для поиска, но я пока не думаю, что они там есть. Coverity может показаться лучшим выбором, но, похоже, у них есть только некоторый динамический анализ для проблем с потоками Java.

Эта статья претендует на то, чтобы сделать это, но я не рассматривал ни одной детали: Композиционный анализ программ на C / C ++ с VeriSoft . Связано это [PDF] Обоснование / гарантия с помощью компьютера с VeriSoft . Похоже, вы должны вручную аннотировать исходный код для обозначения интересующих элементов моделирования. Сам инструмент Verifysoft, по-видимому, является собственностью Bell Labs и, вероятно, его сложно получить.

Аналогично этому: Распределенная проверка многопоточных программ на C ++ .

Эта статья также делает интересные заявления, но не обрабатывает C ++, несмотря на заголовок: Проверка модели выполнения многопоточных программ на C / C ++ .

Хотя все эти части сложны, проблема, с которой они все сталкиваются, - это синтаксический анализ C ++ (на примере ранее цитируемый документ) и поиск шаблонов кода, которые предоставляют необработанную информацию для модели. Вам также необходимо проанализировать конкретный диалект C ++, который вы используете; не приятно, что все компиляторы C ++ принимают разные языки. И, как вы заметили, обработка больших кодов C ++ необходима. Шашки моделей (SPIN и друзья) найти довольно легко.

Наш DMS Software Reengineering Toolkit обеспечивает синтаксический анализ общего назначения с настраиваемым сопоставлением шаблонов и извлечением фактов, а также имеет надежный C ++ интерфейс , который обрабатывает многие диалекты C ++ (EDIT, февраль 2019: включая C ++ 17 в вариантах Ansi, GCC и MS). Скорее всего, он может быть настроен на поиск и извлечение фактов, соответствующих модели, которая вас интересует. Но это не делает это с полки.

DMS с интерфейсом C были использованы для обработки чрезвычайно больших приложений C (19 000 единиц компиляции!). Интерфейс C ++ использовался с гневом во многих крупномасштабных проектах C ++ (EDIT, февраль 2019 года: включая масштабный рефакторинг API для более чем 3000 модулей компиляции). Учитывая общие возможности DMS, я думаю, что он, вероятно, способен обрабатывать довольно большие куски кода. YMMV.

Answer 2

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

Вы можете попробовать использовать инструменты автоматического обнаружения инвариантов, такие как "Daikon", которые захватывают воспринимаемые инварианты во время выполнения. Вы можете проверить позже, если обнаруженные инварианты (например, эквивалентность переменных "a == b + 1") имеют смысл, и затем вставить постоянные утверждения в ваш код. Таким образом, когда инвариант нарушается в результате вашего изменения, вы получите предупреждение о том, что, возможно, вы что-то сломали в результате своего изменения. Этот метод помогает избежать реструктуризации или изменения кода для добавления тестов и макетов.

Answer 3

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