Возможности статического анализатора Atollic TrueINSPECTOR для повышения качества встраиваемых приложений

Введение

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

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

Часть из них выявляется и устраняется разработчиками на этапе отладки ПО. Однако другая часть может быть вовсе неизвестна разработчикам, соответственно, все эти ошибки так и останутся не исправленными. В дальнейшем некоторые из этих ошибок могут быть выявлены только на этапе тестирования, а с другими уже столкнутся недовольные клиенты, и это случится уже после того, как продукт будет выпущен [1].

Для того чтобы вообще избежать большей части проблем еще на этапе разработки ПО или по крайней мере исправить проблемы до начала его тестирования, существует достаточно эффективный подход. И его применение не требует больших дополнительных усилий и времени. Использование специальных автоматизированных инструментов, таких как Atollic TrueSTUDIO [2], предоставляет возможность проведения статического анализа исходного кода и сбора метрик кода. На основании полученных данных разработчики смогут своевременно внести ряд улучшений в свой код. Как следствие, компания, разрабатывающая встраиваемые системы, сможет с меньшими усилиями поставлять ПО более высокого качества.

Ранее обнаруженные ошибки обойдутся дешевле

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

Рис. 1. Исправлять программные проблемы на ранних стадиях разработки дешевле

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

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

Статический анализ исходного кода

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

Эти инструменты выполняют синтаксический разбор (парсинг) исходного кода программы и анализируют, как он написан. Данный анализ, как правило, делится на два различных направления: соответствие стандартам кодирования и сбор метрик исходного кода.

Большинство инструментов, которые выполняют статический анализ исходного кода, проверяют стиль кодирования на соответствие формальным стандартам (существует множество различных стандартов кодирования, один из самых популярных в отрасли встраиваемых систем в настоящее время — это MISRA-C:2004, он будет подробнее рассмотрен следующем разделе).

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

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

Важно понимать, что сложность кода в C‑функциях не имеет ничего общего с тем, сколько строк кода они содержат. Короткая функция бывает очень сложной, и в то же время объемные функции могут быть написаны с низкой сложностью.

Многие компании начали понимать качественные преимущества соблюдения таких стандартов кодирования, как MISRA-C. Основываясь на них, они формируют серию руководящих корпоративных указаний в духе: файлы исходного кода должны иметь определенный процент построчного комментирования или же C‑функции не могут превышать определенный порог сложности и т. д.

Средства статического анализа исходного кода должны быть интегрированы в C/C++ IDE для того, чтобы упростить их ежедневное использование. В частности, инструмент Atollic TrueINSPECTOR [3] интегрирован и включен в среду разработки Atollic TrueSTUDIO IDE (рис. 2).

Рис. 2. Инструмент Atollic TrueINSPECTOR интегрирован в среду разработки Atollic TrueSTUDIO

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

Правильный подход — использовать инструменты статического анализа кода ежедневно или даже ежечасно, с самого начала проекта. Тогда будет обеспечено высокое качество постепенной и итеративной разработки, где все дополнения и модификации кода проверены и исправлены сразу же, по мере их добавления.

Соответствие стандартам кодирования

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

Стандарт MISRA (Motor Industry Software reliability Association) изначально был создан для автомобильной промышленности совместными усилиями нескольких поставщиков. В 1998 году появилось первое издание стандарта — “Guidelines for the use of the C language in vehicle based software” («Руководство по применению языка C для встраиваемого автомобильного програм-много обеспечения») [4]. Цель публикации — популяризировать лучшие практики в разработке критичных по безопасности систем для автотранспорта. Документ содержит 127 правил, 93 из них являются обязательными, а 34 носят рекомендательный характер.

По мере развития стандарт стал применяться и для некоторых других видов встраиваемых систем. На сегодня MISRA-C уже широко используется во всех типах встраиваемых систем, включая и проекты, не критичные по безопасности. В 2004 году вышло обновленное издание “Guidlines for the use of the C language in critical systems” («Руководство по применению языка C для критичных систем») [5]. Эта редакция содержит уже 141 правило, 121 из них носит обязательный характер, а 20 — рекомендательный. MISRA-C:2004 является более универсальным и лучше адаптирован для любого типа встраиваемых систем (рис. 3).

Рис. 3. Выбор правил MISRA-C в настройках инструмента Atollic TrueINSPECTOR

Разработчики встраиваемых систем, которые следуют стандарту кодирования MISRA-C, получают гарантию того, что при создании их программ не используются потенциально небезопасные или ненадежные конструкции кода. Таким образом, они могут устранить потенциальные проблемы с программным обеспечением и улучшить техническую поддержку готового продукта после его запуска в эксплуатацию. Следовательно, качество выпускаемого программного обеспечения повышается и в целом.

Однако обеспечить соответствие разрабатываемого программного кода стандарту MISRA-C без специальных инструментов практически невозможно. Здесь требуется средство автоматизации процесса статического анализа исходного кода.

Один из таких инструментов — Atollic TrueINSPECTOR, предназначенный именно для анализа кода программ для встраиваемых систем. Он выполняет автоматическую проверку исходного кода на соответствие стандарту MISRA-C:2004 и указывает на любые строки кода, в которых обнаружено несоблюдение правил, установленных стандартом.

Метрики исходного кода

Соответствие кода общепринятому стандарту, такому как MISRA-C, дает немало преимуществ. Но помимо этого, для дальнейшего уменьшения вероятности возникновения проблем с программным обеспечением и повышения удобства технической поддержки готового продукта могут быть использованы метрики кода.

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

Между тем, как показывает практика, при совершенствовании стиля кодирования наиболее полезны следующие показатели: степень комментирования и цикломатическая сложность кода.

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

Цикломатическая сложность кода является показателем того, насколько сложна реализация программы. Стиль слишком сложных C‑функций следует упростить в целях недопущения ошибок и облегчения технического сопровождения.

Теория вычисления цикломатической сложности программного кода разработана Томасом Дж. Маккейбом (Thomas J. McCabe) в 1976 году и описывает способ измерения числа линейно независимых путей в исходном коде программ [6].

В таблице 1 приведена зависимость риска возникновения ошибок от уровня сложности программного кода.

В таблице 2 приведена вероятность возникновения новых проблем при устранении (bug fixing) обнаруженных ранее.

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

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

Инструменты статического анализа исходного кода для встраиваемых приложений

Для разработчиков очень удобно, если такие анализаторы уже интегрированы в применяемую ими среду разработки. К примеру, в комплекте поставки среды Atollic TrueSTUDIO C/C++ IDE предусмотрен обязательный компонент Atollic TrueINSPECTOR. Это инструмент, ориентированный на работу со встраиваемыми приложениями и выполняющий статический анализ исходного кода таких программ, как проверка соответствия кода стандарту MISRA-C:2004 и вычисление метрик кода.

Для удобства восприятия результаты работы Atollic TrueINSPECTOR могут быть представлены в различных визуальных форматах (графики, таблицы, диаграммы), а для упрощения навигации графический интерфейс программы снабжен необходимым набором гиперссылок. В частности, сводная статистика по обнаруженным нарушениям правил (рис. 4) и по степени критичности проблем (рис. 5) предоставляется в виде списка и в формате диаграммы с богатым набором опций поиска и фильтрации.

Рис. 4. Сводная статистика по обнаруженным нарушениям правил

Рис. 5. Сводная статистика по степени критичности проблем

Особый интерес разработчиков представляет обнаружение фактических нарушений стандарта MISRA-C. Для этих целей форма отображения результатов анализа содержит подробную информацию о конкретных нарушениях, с гиперссылками на соответствующие строки в файлах исходного кода. Форма просмотра правил включает детальное описание каждого правила кодирования MISRA-C, а также отображает плохие и хорошие примеры кода, выступая в качестве удобного учебного пособия (рис. 6).

Рис. 6. Список нарушений правил и их описание в Atollic TrueINSPECTOR

И все же важно понимать, что поскольку стандарт MISRA-C:2004 содержит достаточно большой набор правил, то подобными инструментальными средствами могут быть выполнены не все проверки, а только большая их часть. И оценка качества различных анализаторов кода вычисляется на базе того, как много правил способен обнаружить тот или иной инструмент.

Производители Atollic TrueINSPECTOR заявляют распознавание 124 из 141 возможного правила стандарта MISRA-C:2004 — это весьма высокая характеристика среди аналогов на рынке. Для сравнения: большинство распространенных подобных инструментов держат планку на уровне распознавания около 100 правил, а значит, коэффициент их полезности несколько ниже.

Следует также уделить внимание и второму показателю качества инструментов проверки соответствия MISRA-C — насколько хорошо он обнаруживает каждое правило стандарта. Для того чтобы произвести подобную оценку, сам стандарт MISRA-C включает специальный типовой набор, содержащий 662 теста. По результатам их прохождения можно судить о качестве распознавания каждого из правил. Безусловно, хороший инструмент должен не только обнаруживать правила, но и делать это лучшим образом, успешно проходя наибольшее число тестов из набора.

Так что при выборе инструмента для использования его в проекте разработчики должны обязательно уточнить у поставщика, какое количество правил MISRA-C обнаруживает тот или иной инструмент и сколько тестов из стандартного набора он проходит.

Как видно на рис. 7, Atollic TrueINSPECTOR — один из лучших инструментов в своей области. Он способен обнаруживать 124 правила соответствия стандарту MISRA-C, а также успешно проходит 619 из 662 тестов из типового тестового набора. И эти показатели намного лучше, чем у большинства аналогов.

Рис. 7. Сравнение показателей эффективности анализаторов кода, представленных на рынке

Кроме того, Atollic TrueINSPECTOR выполняет вычисление метрик исходного кода на уровне проекта, файлов и функций. Это позволяет разработчикам просматривать статистику по таким параметрам, как количество строк в файлах, количество строк в функции, уровень комментирования и сложность кода C‑функций (рис. 8, 9).

Рис. 8. Метрики кода в Atollic TrueINSPECTOR

Рис. 9. Метрики кода в Atollic TrueINSPECTOR

Аналитические отчеты с результатами измерений могут быть экспортированы в форматы PDF, HTML и Microsoft Office (рис. 10). Таким образом, возможен последующий анализ результатов в автономном режиме или составление технических показательных отчетов для руководства или клиентов.

Рис. 10. Сгенерированный отчет содержит результаты анализа

Заключение

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

Новые встроенные инструменты, такие как Atollic TrueINSPECTOR, легко интегрируются в среду разработки программных приложений на языке C/C++ и предоставляют возможность автоматизированного анализа кода. Они указывают на потенциальные проблемы кодирования и обеспечивают более удобное и быстрое сопровождение программного обеспечения.

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

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