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

DOI:

Сбор метрической информации о коде – один из самых легко реализуемых методов статического анализа кода. На основе собранных данных делается вывод о среднем количестве ошибок и о месте их наиболее

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

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

– иерархия наследования при использовании объектно-ориентированного подхода. Запутанная и сложная схема наследования классов также приводит к трудностям в понимании и поддержкой кода, что, в свою очередь, увеличивает вероятность нахождения ошибки в этих частях кода. Данная метрика вычисляет глубину наследования (количество классов-предков) и количество классов, имеющих общего родителя. Классы, имеющие длинное генеалогическое дерево аккумулируют в себя ошибки классов-предшественников, поэтому им должно уделяться особое внимание со стороны разработчиков. Аналогично, класс, имеющий множество наследников, должен быть также верифицирован тщательным образом. Для языков с поддержкой множественного наследования (например, С++) эта метрика играет особо важную роль, показывая сколько родительских классов имеет дочерний класс;

– цикломатическая сложность. Термин, как и сама метрика, была предложена Томасом Мак-Кейбом в 1976 году. Представляет собой количество линейно независимых путей выполнения на рассматриваемом участке программы. Анализируемый участок может быть отдельной функцией, классом или целым модулем. Цикломатическая сложность вычисляется на основе графа потока управления (CFG). Узлами CFG являются базовые блоки кода (участки кода, не содержащие ветвлений), а ребра – переходы управления между базовыми блоками. Значение цикломати-ческой сложности рассчитывается по следующей формуле:

M = E - N + 2 x P , (1)

где M – значение циклической сложности; E – количество ребер в графе; N – количество узлов в графе; P – компонента связности графа. В своей работе «A Complexity Measure» МакКейб рекомендует перерабатывать код приложения таким образом, чтобы цикломати-ческая сложность не превышала значения 10. С момента написания этой работы в 1976 г. эта практика пересматривалась многими специалистами, в том числе и Национальным институтом стандартов и технологий США, однако рекомендуемое значение до сих пор остается прежним;

– вычислительная сложность. Определение сложности фрагмента кода в виде O-нотации позволяет делать выводы о взаимозависимости входных параметров. Если формула сложности содержит произведение каких-либо входных параметров, это говорит об их взаимозависимости. В большинстве случаев, алгоритмы, имеющие большое количество взаимозависимостей во входных данных сложны для разработки и понимания и, как следствие, часто содержат ошибки. Если же формула сложности включает в себя множество слагаемых, то описываемый алгоритм содержит в себе независимые вычисления, которые необходимо разносить по отдельным программным модулям для упрощения их поддержки [1];

– метрики Холстеда. Метрическая теория программ М.Х. Холстеда исходит из статистического выражения алгоритма на конкретном языке программирования. В своей работе «Elements of software science» [2] он предлагает следующие характеристики исходных кодов: η ₁ – число простейших операторов в программе; η ₂ – число простейших операндов; N 1 – общее число операторов; N 2 – общее число операндов; f_j1 – число вхождений j -го наиболее часто встречающегося оператора ( j = \ П )'; f₂ — число вхождений j -го наиболее часто встречающегося оператора ( j = Щ ). Отправляясь от этих базовых метрических характеристик Холстед определяет так же понятия словаря

η = η₁ + η₂ , (2)

длины реализации алгоритма

Г.А. Попов, М.М. Жунёва. Сбор метрик программного кода для анализа его уязвимостей

N = N ₁ + N ₂,                (3)

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

V = N log₂ η ,                 (4)

Холстед отмечает, что этот параметр не может однозначно характеризовать реализацию алгоритма ввиду наличия избыточности в программном коде. На основании данного вывода он вводит понятия потенциальных (минимальных) метрических характеристик ( η , V ^* и т. д.), описывающих данный алгоритм в наиболее сжатой его форме. Отличие данной реализации алгоритма от потенциального Холстед выразил понятием уровня программы

V ^*

V

и вывел формулу для его практического расчета

_{L ˆ =} η _1* η ₂ η 1 N 2 .

Наконец, Холстед определяет важнейшую характеристику языка программирования – уровень языка л = LV* = L2V.                (7)

Одним из приложений теории Холстеда является гипотеза ошибок [3], с помощью которой можно предсказать ожидаемое количество ошибок в программе. Автор предлагает следующую формулу для оценки количества переданных программе ошибок:

B ^ˆ = ^{E крит ( V * )} , (8) λ ³

где V = ( η ₁ + η ₂)log₂( η ₁ + η ₂) – потенциальный объем программы, а E_крит – число элементарных мысленных различений, требуемых для ее порождения.

Последняя характеристика отражает способность мозга удерживать в памяти несколько объектов одновременно. В заключении Холстед приводит расчеты для английского языка (λ = 2,16, E_крит = 3000), подтверждаемые экспериментальными исследованиями.

Подводя итог к вышеприведенному описанию метрик программного кода, можно выделить следующие существенные факты:

• 1.    Метрики программного кода собираются на основе совокупности всех исходных файлов проекта, а потому обладают потенциальной возможностью 100%-ного покрытия кода.

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

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

• 4.    Процесс сбора метрической информации не требует дополнительных усилий со стороны разработчиков.

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

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