ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 24.11.2023
Просмотров: 36
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Метрики как средство управления качеством
На быстрорастущем рынке программного обеспечения сегодня существенно растут требования к скорости разработки и качеству ПО. Использование гибкой архитектуры и различных приемов проектирования, безусловно, способно повысить качество разработок, однако формальные критерии качества, например метрики кода, показывающие количественные характеристики программной системы в различных измерениях, по-прежнему остаются актуальными.
С
учетом новых методик, таких как экстремальное программирование или Scrum, разработка может осуществляться быстрее, а наличие новых платформ и абстрагирование от нижних уровней позволяют избегать многих ошибок. Тем не менее контроль качества должен осуществляться на самых различных уровнях – начиная с методологического и заканчивая технологическим уровнем, когда процессы контроля качества протекают в автоматическом режиме, например при автоматических сборках проекта. Однако любой контроль предполагает наличие метрик, которые позволяют оценить достижение того или иного уровня качества программного проекта.Метрики кода
Метрика программного обеспечения (software metric) – численная мера, позволяющая оценить определенные свойства конкретного участка программного кода. Для каждой метрики обычно существуют ее эталонные показатели, указывающие, при каких крайних значениях стоит обратить внимание на данный участок кода. Метрики кода разделяются на категории и могут оценивать совершенно различные аспекты программной системы: сложность и структурированность программного кода, связность компонентов, относительный объем программных компонентов и др. Наиболее простая для понимания метрика – количество строк кода в программной системе, – хотя и элементарно вычисляется, но в совокупности с другими метриками может служить для получения формализованных данных для оценки кода. Например, можно построить соотношение между количеством строк кода в классе и количеством методов/свойств в классе, получив характеристику, показывающую, насколько методы данного класса являются объемными. Кроме того, такие оценки можно использовать в совокупности с метриками сложности (например, цикломатической сложностью Мак-Кейба) для определения наиболее сложных участков в программном коде и принятия соответствующих мер.
М
етрики кода могут служить также для выявления архитектурных особенностей. Наибольший эффект применение таких метрик дает при анализе больших программных систем, когда ручной анализ и просмотр исходного кода может занимать значительное время. Например, можно различным образом визуализировать метрики, как указано на рис. 1, где каждый программный блок представляется в виде прямоугольника, при этом длина каждой стороны прямоугольника отражает значение какой-либо из метрик (например, сложность, структурированность и т.д.). Подобное представление можно строить как для высокоуровневых программных сущностей (сборки, библиотеки, пространства имен), так и для более частных элементов (свойства, методы). При этом при анализе высокоуровневой диаграммы можно быстро выявить проблемные библиотеки и спуститься на уровень ниже, чтобы исследовать проблемные сущности.Метрики программного кода являются важным инструментом и уже сегодня используются многими производителями ПО. Так, при сертификации на более высокие уровни по моделям ISO/IEC или CMM/CMMI использование метрик кода является обязательным, что позволяет в определенной степени достичь контролируемости процесса разработки.
Существует множество различных классификаций метрик программного обеспечения, трактующих метрики с различных позиций и ранжирующих одни и те же характеристики по различным критериям. Одной из таких классификаций может служить разделение метрик на группы по субъектам оценки:
-
размер – сравнительная оценка размеров ПО; -
сложность – оценка архитектуры и алгоритмов программной системы (отрицательные показатели этой группы метрик говорят о проблемах, с которыми можно столкнуться при развитии, поддержке и отладке программного кода); -
поддерживаемость – оценка потенциала программной системы для последующей модификации.
Безусловно, существуют и другие группы, которые не вошли в эту классификацию, например, метрики удовлетворенности пользователя или показатели соответствия исходным требованиям, но в данном случае нас будет интересовать качество программного обеспечения с точки зрения именно технической реализации.
Имеет ли значение размер?
Метрика SLOC (source lines of code) отражает количество строк исходного кода. Данный показатель не всегда может использоваться для объективной оценки объемов программной системы – его числовое значение зависит от множества случайных факторов, например стиля кодирования. Сравнивать две программные системы лишь по этому критерию вряд ли правомерно, поэтому для SLOC появилось множество производных показателей:
количество пустых строк; количество строк, содержащих комментарии; процентное соотношение комментариев; количество строк кода, содержащихся в методах/функциях; среднее количество строк кода на метод/функцию; среднее количество строк кода на класс/пакет; среднее количество строк кода на модуль и т.д.
Кроме SLOC, при оценке размера часто используют показатель «логических» строк кода LSI (logical source instructions), вычисляемый после нормализации (приведения исходного кода к надлежащему виду) листинга: устранение размещения нескольких инструкций на одной строке, пустых строк, очистка от комментариев, форматирование строк кода для инициализации данных и т.д. Такой показатель может служить для более объективной оценки объема системы (показатель с применением нормализации выглядит так же, как и SLOC, – количество строк, но не физических, а логических). У LSI также существуют производные, например метрика, вычисляемая не как физическое количество строк кода на исходном языке программирования, а как количество инструкций на языке более низкого уровня (язык Ассемблера, MSIL и др.), что устраняет необходимость в нормализации.
Другие метрики этого типа базируются на сущностях, относящихся к конкретной парадигме программирования. Наиболее популярной на сегодняшний день является парадигма объектно-ориентированного программирования, однако для функционального и процедурного подхода к программированию также имеется свой специфический набор метрик. С точки зрения объектно-ориентированного подхода размер системы можно вычислять как количество содержащихся в ней классов. Показатель количества классов является одной из основных метрик в данном подходе, однако в зависимости от используемого языка программирования могут применяться такие метрики, как количество пространств имен в проекте, количество структур, перечислений, количество методов и др. Кроме того, можно вычислить «плотность» этих показателей, определив соотношение значений этих метрик. Например, можно вычислить соотношение количества классов к количеству методов и понять, сколько методов в среднем содержится в одном классе. Однако для определения пороговых значений для такого типа метрик требуются дополнительные исследования. Наиболее простым способом определения граничных величин может быть эксперимент
, в котором значения этих метрик вычисляются для уже существующих систем. Вычисление подобных соотношений позволит скорректировать представление о системе, которое сложилось на основе количественных метрик.
Напрямую качество системы не зависит от использования данных показателей, однако опытные разработчики со временем могут примерно прогнозировать объем системы на заданный функционал, необходимый заказчику. В этом случае при заметном отклонении от заданных показателей (например, существенном увеличении количества классов при низком количестве методов на класс) стоит задуматься о том, что в системе может присутствовать избыточное количество объектов, и на более ранней стадии выполнить рефакторинг кода.
Сложность
Для оценки и контроля качества кода могут непосредственно использоваться метрики сложности: цикломатическая сложность, связность кода, глубина наследования и др.
Метрика цикломатической сложности (cyclomatic complexity) показывает количество ветвлений управляющего потока программы, увеличенное на единицу. Для вычисления данной метрики на основе исходного кода строится ориентированный граф, содержащий один вход и один выход. При этом вершины графа соотносят с теми участками кода программы, в которых содержатся лишь последовательные вычисления и отсутствуют операторы ветвления и цикла. Дуги в этом случае соотносят с переходами от блока к блоку. При этом каждая вершина графа достижима из начальной, а конечная точка достижима из любой другой. В этом случае цикломатическую сложность можно вычислить как разницу количества дуг и количества вершин, увеличенную на два. Такой показатель может отразить сложность управляющего потока программы и дать сигнал о возможном наличии некачественного участка кода. К сожалению, несмотря на очевидную практическую полезность, эта метрика не способна различать циклические операторы. Кроме того, программные коды, представленные одними и теми же графами, могут иметь совершенно различные по сложности предикаты (логические выражения, содержащие переменную). По этой причине иногда цикломатическую сложность используют одновременно с другими метриками, например с метрикой числа операторов.
Метрика связности классов позволяет определить степень зависимости программных компонентов системы друг от друга. Повышенные значения данной метрики относительно пороговых значений могут говорить о чрезмерной связанности системы
, которая появляется из-за слабой модульной инкапсуляции. Такое свойство программной системы может привести к трудностям при повторном использовании кода. На данную метрику можно ориентироваться при построении и переработке архитектуры программной системы. Основными способами уменьшения связности объектов является более строгая инкапсуляция логики в объекты, пересмотр работы алгоритмов с концептуальной точки зрения и структурная декомпозиция. При этом используются фабрики объектов, которые позволяют избежать лишней связности в момент создания экземпляров классов. Благодаря применению сырых значений данной метрики удается снизить связность программной системы, а следовательно, и сложность кода.
Иногда используют вариацию метрики, отражающей связность кода, – количество вызовов операции. Эта метрика позволяет определить количественный показатель связности системы в виде вызовов методов. Метрика подсчитывает вызовы только тех операций, которые определены пользователем. Например, если метод A() вызывает метод B() три раза, то значение этой метрики будет равно единице; если же метод B() вызывается по одному разу из методов A(), C() и D(), то значение метрики будет равняться трем. Однако абсолютное значение данной метрики может существенно изменяться от проекта к проекту в зависимости от подходов к проектированию и кодированию программных систем. Даже в рамках одной и той же команды разработчиков на идентичных проектах значение данной метрики может отличаться в силу субъективных факторов (например, стиля конкретного разработчика при выделении логики в отдельные методы), которые оказывали влияние при построении программной системы.
Прямой результат вычисления этой метрики имеет сомнительное практическое значение, однако в совокупности с суммарным значением метрики количество методов в классе может дать объективную оценку связности системы. Например, если использовать эту метрику наряду с метрикой сложности, а также объемными характеристиками, то по совокупности значений этих метрик можно обнаружить недостаточно качественный код.
Еще одной важной метрикой оценки сложности является средняя глубина наследования, которая вычисляется как среднее значение глубины наследования для всех классов системы, определенных пользователем. При этом не учитываются классы, стоящие не на самом нижнем уровне иерархии наследования. Высокие значения метрики могут сигнализировать о том, что архитекторы программной системы слишком увлеклись