Анна Сергеева. Возможности статического анализатора Atollic TrueINSPECTOR для повышения качества встраиваемых приложений // Компоненты и технологии. 2015. № 4. С. 121-125.
Программные приложения для современных встраиваемых систем содержат более сложный и объемный код, чем это было всего несколько лет назад. Значит, возрастает степень угроз снижения качества производимого ПО. А для критичных по безопасности встраиваемых систем это чрезвычайно важный вопрос.
Для борьбы с такими проблемами существуют различные достаточно эффективные стратегии, среди которых метод статического анализа исходного кода и сбора метрик исходного кода.
В статье рассмотрены преимущества его применения. Также приведены используемые на практике инструменты, которые позволяют разработчикам встраиваемых систем выявлять потенциальные проблемы автоматически, а значит, добиваться более высокого качества ПО с минимальными усилиями.
Опубликовано в разделе "Встраиваемые системы"
Эта же статья на сайте журнала
Введение
Практика подсказывает, что подавляющее большинство программных продуктов содержит те или иные ошибки. И если какой-либо производитель ПО полагает, что его продукт является счастливым исключением, то скорее всего, он просто не знает об ошибках в своем коде и не столкнулся с их проявлением.
С ростом объема кода увеличивается сложность и количество возникающих программных проблем, а это значит, что для более сложного ПО вероятность возникновения ошибок и проблем будет более высокой.
Часть из них выявляется и устраняется разработчиками на этапе отладки ПО. Однако, другая часть может быть вовсе неизвестна разработчикам, а значит, все эти ошибки так и останутся - не исправленными. В дальнейшем, некоторые из этих ошибок могут быть выявлены только на этапе тестирования, а с другими уже столкнутся недовольные клиенты, и это случится уже после того как продукт будет выпущен. [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 — это стандарт кодирования, разработанный 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 приведена зависимость риска возникновения ошибок от уровня сложности программного кода.
Таблица 1. Зависимость риска возникновения ошибок от уровня сложности программного кода.
|
Уровень сложности |
Тип функции |
Риск ошибок |
|
От 1 до 4 |
Простая функция |
Низкий |
|
От 5 до 10 |
Хорошо структурированная |
Низкий |
|
От 11 до 20 |
Сложная функция |
Средний |
|
От 21 до 50 |
Угрожающе сложная функция |
Высокий |
|
Более 50 |
Подверженная ошибкам и непроверяемая функция |
Очень высокий |
А в таблице 2 приведена вероятность возникновения новых проблем при устранении (bug fixing) обнаруженных ранее.
Таблица 2. Вероятность возникновения новых проблем при устранении обнаруженных ранее.
|
Уровень сложности |
Риск новых ошибок при устранении существующих |
|
От 1 до 10 |
5% |
|
От 20 до 30 |
20% |
|
От 30 до 60 |
40% |
|
Более 60 |
60% |
Уровни сложности, принимаемые на уровне проекта или всей компании, могу различаться в зависимости от того или иного разрабатываемого продукта, от отрасли или от политики руководства компании. Однако, есть мнение, что ни одна функция не должна иметь показатель сложности выше 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. Сравнение показателей эффективности анализаторов кода, представленных на рынке
Как видно из рис. 7, Atollic TrueINSPECTOR - один из лучших инструментов в своей области. Он способен обнаруживать 124 правила соответствия стандарту MISRA-C, а также успешно проходит 619 из 662 тестов из типового тестового набора. И эти показатели намного лучше, чем у большинства аналогов.
Кроме того, Atollic TrueINSPECTOR выполняет вычисление метрик исходного кода на уровне проекта, файлов и функций. Это позволяет разработчикам просматривать статистику по таким параметрам как количество строк в файлах, количество строк в функции, уровень комментирования и сложность кода C-функций (рис. 8 и 9).
Рис. 8. Метрики кода в Atollic TrueINSPECTOR
Рис. 9. Метрики кода в Atollic TrueINSPECTOR
Аналитические отчеты с результатами измерений могут быть экспортированы в форматы PDF, HTML и Microsoft Office (рис.10). Таким образом, возможен последующий анализ результатов в автономном режиме или составление технических показательных отчетов для руководства или клиентов.
Рис. 10. Сгенерированный отчет содержит результаты анализа
Заключение
Возможности современных микропроцессоров растут с каждым годом, а значит, они получают способность поддерживать все более объемные и сложные встраиваемые программные приложения. Соответственно, увеличивается сложность и размер кода таких программ. Так что вопросам обеспечения высокого качества разрабатываемых программ приходится уделять все больше и больше внимания. И для критичных встраиваемых систем это имеет особую, принципиальную важность.
Новые встроенные инструменты, такие как Atollic TrueINSPECTOR, легко интегрируются в среду разработки программных приложений на языке C/C++ и предоставляют возможность автоматизированного анализа кода. Они указывают на потенциальные проблемы кодирования и обеспечивают более удобное и быстрое сопровождение программного обеспечения.
С помощью анализаторов кода разработчики могут регулярно и автоматически выполнять проверку своих программ на соответствие стандартам кодирования, необходимому уровню комментирования и установленному пределу сложности функций. И нужно начинать уже на самых ранних стадиях разработки, достаточно регулярно, чтобы тут же, своевременно вносить улучшения в код. При этом, за счет автоматизации процесса, затраты на постоянное применение анализаторов будут минимальными.
Все это приведет к тому, что большинства возможных проблем и ошибок кодирования удастся избежать еще до выпуска готового продукта. Клиенты получат желаемое ПО более высокого качества и останутся довольны приобретением. Соответственно, обращений пользователей в службу технической поддержки будет меньше, и на исправление ошибок уйдет меньше времени, сил и затрат бюджета. И, разумеется, на рейтинге компании-разработчика и выпускаемого ей ПО на рынке будет сказываться только положительно.
Литература
1. А. Сергеева. Тестирование работоспособности промышленного компьютера. // Компоненты и технологии. 2014. № 2.
2. Об среде разработки Atollic TrueSTUDIO - www.atollic.com/truestudio
3. Об инструменте Atollic TrueINSPECTOR - www.atollic.com/trueinspector
4. MISRA-C: "Guidelines for the use of the C language in vehicle based software", 1998.
5. MISRA-C: "Guidlines for the use of the C language in critical systems", 2004.
6. McCabe, Thomas J. A Complexity Measure. // IEEE Transactions on Software Engineering, 1976.