Метрика что это в программировании
Метрики кода и практическая реализация по их сбору и анализу. Часть 1 – метрики
В отличие от большинства отраслей материального производства, в вопросах проектов создания ПО недопустимы простые подходы, основанные на умножении трудоемкости на среднюю производительность труда. Это вызвано, прежде всего, тем, что экономические показатели проекта нелинейно зависят от объема работ, а при вычислении трудоемкости допускается большая погрешность.
Поэтому для решения этой задачи используются комплексные и достаточно сложные методики, которые требуют высокой ответственности в применении и определенного времени на адаптацию (настройку коэффициентов).
Современные комплексные системы оценки характеристик проектов создания ПО могут быть использованы для решения следующих задач:
Оглавление
2. Метрики
Метрики сложности программ принято разделять на три основные группы:
Метрики первой группы базируются на определении количественных характеристик, связанных с размером программы, и отличаются относительной простотой. К наиболее известным метрикам данной группы относятся число операторов программы, количество строк исходного текста, набор метрик Холстеда. Метрики этой группы ориентированы на анализ исходного текста программ. Поэтому они могут использоваться для оценки сложности промежуточных продуктов разработки.
Метрики второй группы базируются на анализе управляющего графа программы. Представителем данной группы является метрика Маккейба.
Управляющий граф программы, который используют метрики данной группы, может быть построен на основе алгоритмов модулей. Поэтому метрики второй группы могут применяться для оценки сложности промежуточных продуктов разработки.
Метрики третьей группы базируются на оценке использования, конфигурации и размещения данных в программе. В первую очередь это касается глобальных переменных. К данной группе относятся метрики Чепина.
2.1 Размерно — ориентированные метрики (показатели оценки объема)
2.1.1 LOC-оценка (Lines Of Code)
Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются такие метрики на LOC-оценках.
Этот вид метрик косвенно измеряет программный продукт и процесс его разработки. Вместо подсчета LOC-оценок при этом рассматривается не размер, а функциональность или полезность продукта.
Наибольшее распространение в практике создания программного обеспечения получили размерно-ориентированные метрики. В организациях, занятых разработкой программной продукции для каждого проекта принято регистрировать следующие показатели:
На основе этих данных обычно подсчитываются простые метрики для оценки производительности труда (KLOC/человеко-месяц) и качества изделия.
Эти метрики не универсальны и спорны, особенно это относится к такому показателю как LOC, который существенно зависит от используемого языка программирования.
| Пример из жизни: На наш взгляд оценка по количеству строк в коде влечёт за собой соблазн написать побольше строк, дабы взять побольше денег. Разумеется, об оптимизации в таком продукте никто уже думать не станет. Вспомним историю о том, как планетарный центр аутсорсинга — Индия, после того, как заказчики вменили им метрику LOC, на второй день показал удвоение и утроение строк кода. |
Количество строк исходного кода (Lines of Code – LOC, Source Lines of Code – SLOC) является наиболее простым и распространенным способом оценки объема работ по проекту.
Изначально данный показатель возник как способ оценки объема работы по проекту, в котором применялись языки программирования, обладающие достаточно простой структурой: «одна строка кода = одна команда языка». Также давно известно, что одну и ту же функциональность можно написать разным количеством строк, а если возьмем язык высокого уровня (С++, Java), то возможно и в одной строке написать функционал 5-6 строк – это не проблема. И это было бы полбеды: современные средства программирования сами генерируют тысячи строк кода на пустяковую операцию.
Потому метод LOC является только оценочным методом (который надо принимать к сведению, но не опираться в оценках) и никак не обязательным.
В зависимости от того, каким образом учитывается сходный код, выделяют два основных показателя SLOC:
Для метрики SLOC существует большое число производных, призванных получить отдельные показатели проекта, основными среди которых являются:
2.1.1.1 Метрика стилистики и понятности программ
Иногда важно не просто посчитать количество строк комментариев в коде и просто соотнести с логическими строчками кода, а узнать плотность комментариев. То есть код сначала был документирован хорошо, затем – плохо. Или такой вариант: шапка функции или класса документирована и комментирована, а код нет.
Fi = SIGN (Nкомм. i / Ni – 0,1)
Суть метрики проста: код разбивается на n-равные куски и для каждого из них определяется Fi
2.1.2 Итого по SLOC
Потенциальные недостатки SLOC, на которые нацелена критика:
И главное помнить: метрика SLOC не отражает трудоемкости по созданию программы
.
Согласитесь, считать трудозатраты по данной метрике глупо – необходима комплексная оценка…
2.2 Метрики сложности
Помимо показателей оценки объема работ по проекту очень важными для получения объективных оценок по проекту являются показатели оценки его сложности. Как правило, данные показатели не могут быть вычислены на самых ранних стадиях работы над проектом, поскольку требуют, как минимум, детального проектирования. Однако эти показатели очень важны для получения прогнозных оценок длительности и стоимости проекта, поскольку непосредственно определяют его трудоемкость.
2.2.1 Объектно-ориентированные метрики
В современных условиях большинство программных проектов создается на основе ОО подхода, в связи с чем существует значительное количество метрик, позволяющих получить оценку сложности объектно-ориентированных проектов.
Метрика
Описание
Мера сложности класса, основанная на том, что класс с большим числом методов, является более сложным, и что метод с большим количеством параметров также является более сложным. При вычислении метрики родительские классы не учитываются.
Связность объектов (Coupling between objects)
Количество модулей, связанных с данным модулем в роли клиента или поставщика. Чрезмерная связность говорит о слабости модульной инкапсуляции и может препятствовать повторному использованию кода.
2.2.2 Метрики Холстеда
Метрика Холстеда относится к метрикам, вычисляемым на основании анализа числа строк и синтаксических элементов исходного кода программы.
Основу метрики Холстеда составляют четыре измеряемые характеристики программы:
На основании этих характеристик рассчитываются оценки:
Показатель цикломатической сложности позволяет не только произвести оценку трудоемкости реализации отдельных элементов программного проекта и скорректировать общие показатели оценки длительности и стоимости проекта, но и оценить связанные риски и принять необходимые управленческие решения.
Упрощенная формула вычисления цикломатической сложности представляется следующим образом:
C = e – n + 2,
где e – число ребер, а n – число узлов
на графе управляющей логики.
Как правило, при вычислении цикломатической сложности логические операторы не учитываются.
В процессе автоматизированного вычисления показателя цикломатической сложности, как правило, применяется упрощенный подход, в соответствии с которым построение графа не осуществляется, а вычисление показателя производится на основании подсчета числа операторов управляющей логики (if, switch и т.д.) и возможного количества путей исполнения программы.
Показатель цикломатической сложности может быть рассчитан для модуля, метода и других структурных единиц программы.
Существует значительное количество модификаций показателя цикломатической сложности.
2.2.4 Метрики Чепина
Существует несколько ее модификаций. Рассмотрим более простой, а с точки зрения практического использования – достаточно эффективный вариант этой метрики.
Суть метода состоит в оценке информационной прочности отдельно взятого программного модуля с помощью анализа характера использования переменных из списка ввода-вывода.
Все множество переменных, составляющих список ввода-вывода, разбивается на четыре функциональные группы.
Далее вводится значение метрики Чепина:
Q = a1P + a2M + a3C + a4T, где a1, a2, a3, a4 – весовые коэффициенты.
Весовые коэффициенты использованы для отражения различного влияния на сложность программы каждой функциональной группы. По мнению автора метрики наибольший вес, равный трем, имеет функциональная группа С, так как она влияет на поток управления программы. Весовые коэффициенты остальных групп распределяются следующим образом: a1=1; a2=2; a4=0.5. Весовой коэффициент группы T не равен нулю, поскольку «паразитные» переменные не увеличивают сложности потока данных программы, но иногда затрудняют ее понимание. С учетом весовых коэффициентов выражение примет вид:
Q = P + 2M + 3C + 0.5T.
2.3 Предварительная оценка на основе статистических методов в зависимости от этапов разработки программы
При использовании интегрированных инструментальных средств у компаний, разрабатывающих типовые решения (под эту категорию попадают так называемые «инхаузеры» – компании, занимающиеся обслуживанием основного бизнеса) появляется возможность строить прогнозы сложности программ, основываясь на собранной статистике. Статистический метод хорошо подходит для решения подобных типовых задач и практически не подходит для прогноза уникальных проектов. В случае уникальных проектов применяются иные подходы, обсуждение которых находится за рамками данного материала.
Типовые задачи как из рога изобилия падают на отделы разработки из бизнеса, потому предварительная оценка сложности могла бы сильно упростить задачи планирования и управления, тем более что есть накопленная база по проектам, в которой сохранены не только окончательные результаты, но и все начальные и промежуточные.
Выделим типовые этапы в разработке программ:
Теперь попробуем рассмотреть ряд метрик, часто используемых для предварительной оценки на первых двух этапах.
2.3.1 Предварительная оценка сложности программы на этапе разработки спецификации требований к программе
Для оценки по результатам работы данного этапа может быть использована метрика прогнозируемого числа операторов Nпрогн программы:
Nпрогн =NF*Nед
Где: NF – количество функций или требований в спецификации требований к разрабатываемой программе;
Nед – единичное значение количества операторов (среднее число операторов, приходящихся на одну среднюю функцию или требование). Значение Nед — статистическое.
2.3.2 Предварительная оценка сложности на этапе определения архитектуры
Си = NI / (NF * NI ед * Ксл)
Где:
NI – общее количество переменных, передаваемых по интерфейсам между компонентами программы (также является статистической);
NIед–единичное значение количества переменных, передаваемых по интерфейсам между компонентами (среднее число передаваемых по интерфейсам переменных, приходящихся на одну среднюю функцию или требование);
Ксл – коэффициент сложности разрабатываемой программы, учитывает рост единичной сложности программы (сложности, приходящейся на одну функцию или требование спецификации требований к программе) для больших и сложных программ по сравнению со средним ПС.
2.4 Общий списочный состав метрик
Таблица 1 содержит краткое описание метрик, не вошедших в детальное описание выше, но тем не менее даные метрики нужны и важны, просто по статистике они встречаются гораздо реже.
Также отметим, что цель этой статьи показать принцип, а не описать все возможные метрики во множестве комбинаций.
Метрики кода программного обеспечения
В работе приведен обзор 7 классов метрик и более 50 их представителей, дано детальное описание и используемые алгоритмы вычисления, описана роль метрик в разработке программного обеспечения.
Введение
Статья является первым этапом работ, осуществляемых ООО «Системы программной верификации» по созданию новых специализированных инструментов для расчета метрик [1]. Она является обзором существующих метрик, который поможет системно подойти к решению ряда задач. Предполагается разработка методологии по оценке сложности переноса программного обеспечения на другие платформы, а также по оценке сложности распараллеливанию кода программы. Данное направление является развитием возможностей продукта PVS-Studio уже не только как статического анализатора, но и как инструмента по прогнозированию трудозатрат программистов при освоении 64-битных систем и адаптации алгоритмов к многоядерным системам.
В данной статье будут представлен широкий спектр метрик программного обеспечения. Естественно, все существующие метрики приводить не целесообразно, большинство из них никогда не применяется на практике либо из-за невозможности дальнейшего использования результатов, либо из-за невозможности автоматизации измерений, либо из-за узкой специализации данных метрик, однако существуют метрики, которые применяются достаточно часто, и их обзор как раз будет приведен ниже.
В общем случае применение метрик позволяет руководителям проектов и предприятий изучить сложность разработанного или даже разрабатываемого проекта, оценить объем работ, стилистику разрабатываемой программы и усилия, потраченные каждым разработчиком для реализации того или иного решения. Однако метрики могут служить лишь рекомендательными характеристиками, ими нельзя полностью руководствоваться, так как при разработке ПО программисты, стремясь минимизировать или максимизировать ту или иную меру для своей программы, могут прибегать к хитростям вплоть до снижения эффективности работы программы. Кроме того, если, к примеру, программист написал малое количество строк кода или внес небольшое число структурных изменений, это вовсе не значит, что он ничего не делал, а может означать, что дефект программы было очень сложно отыскать. Последняя проблема, однако, частично может быть решена при использовании метрик сложности, т.к. в более сложной программе ошибку найти сложнее.
1. Количественные метрики
Кроме SLOC к количественным характеристикам относят также:
количество пустых строк,
процент комментариев (отношение числа строк, содержащих комментарии к общему количеству строк, выраженное в процентах),
среднее число строк для функций (классов, файлов),
среднее число строк, содержащих исходный код для функций (классов, файлов),
среднее число строк для модулей.
Также к группе метрик, основанных на подсчете некоторых единиц в коде программы, относят метрики Холстеда [2]. Данные метрики основаны на следующих показателях:
разделители, имена процедур и знаки операций (словарь операторов),
Учитывая введенные обозначения, можно определить:
При применении метрик Холстеда частично компенсируются недостатки, связанные с возможностью записи одной и той же функциональности разным количеством строк и операторов.
Еще одним типом метрик ПО, относящихся к количественным, являются метрики Джилба. Они показывают сложность программного обеспечения на основе насыщенности программы условными операторами или операторами цикла. Данная метрика, не смотря на свою простоту, довольно хорошо отражает сложность написания и понимания программы, а при добавлении такого показателя, как максимальный уровень вложенности условных и циклических операторов, эффективность данной метрики значительно возрастает.
2. Метрики сложности потока управления программы
Следующий большой класс метрик, основанный уже не на количественных показателях, а на анализе управляющего графа программы, называется метрики сложности потока управления программ.
Перед тем как непосредственно описывать сами метрики, для лучшего понимания будет описан управляющий граф программы и способ его построения.
Пусть представлена некоторая программа. Для данной программы строится ориентированный граф, содержащий лишь один вход и один выход, при этом вершины графа соотносят с теми участками кода программы, в которых имеются лишь последовательные вычисления, и отсутствуют операторы ветвления и цикла, а дуги соотносят с переходами от блока к блоку и ветвями выполнения программы. Условие при построении данного графа: каждая вершина достижима из начальной, и конечная вершина достижима из любой другой вершины [4].
Для исправления данного недостатка Г. Майерсом была разработана новая методика. В качестве оценки он предложил взять интервал (эта оценка еще называется интервальной) [V(G),V(G)+h], где h для простых предикатов равно нулю, а для n-местных h=n-1. Данный метод позволяет различать разные по сложности предикаты, однако на практике он почти не применяется.
Данные меры учитывает уровень вложенности и протяженность программы.
Каждой вершине присваивается своя сложность в соответствии с оператором, который она изображает. Эта начальная сложность вершины может вычисляться любым способом, включая использование мер Холстеда. Выделим для каждой предикатной вершины подграф, порожденный вершинами, которые являются концами исходящих из нее дуг, а также вершинами, достижимыми из каждой такой вершины (нижняя граница подграфа), и вершинами, лежащими на путях из предикатной вершины в какую-нибудь нижнюю границу. Этот подграф называется сферой влияния предикатной вершины.
Приведенной сложностью предикатной вершины называется сумма начальных или приведенных сложностей вершин, входящих в ее сферу влияния, плюс первичная сложность самой предикатной вершины.
Функциональным отношением (SCORT) называется отношение числа вершин в управляющем графе к его функциональной сложности, причем из числа вершин исключаются терминальные.
SCORT может принимать разные значения для графов с одинаковым цикломатическим числом.
Метод граничных значений так же основан на анализе управляющего графа программы. Для определения данного метода необходимо ввести несколько дополнительных понятий.
Каждая принимающая вершина имеет приведенную сложность, равную 1, кроме конечной вершины, приведенная сложность которой равна 0. Приведенные сложности всех вершин графа G суммируются, образуя абсолютную граничную сложность программы. После этого определяется относительная граничная сложность программы:
Существует метрика Шнейдевинда, выражающаяся через число возможных путей в управляющем графе.
3. Метрики сложности потока управления данными
Метрика Чепина: суть метода состоит в оценке информационной прочности отдельно взятого программного модуля с помощью анализа характера использования переменных из списка ввода-вывода.
Все множество переменных, составляющих список ввода-вывода, разбивается на 4 функциональные группы :
Поскольку каждая переменная может выполнять одновременно несколько функций, необходимо учитывать ее в каждой соответствующей функциональной группе.
Q = a1*P + a2*M + a3*C + a4*T,
Весовые коэффициенты использованы для отражения различного влияния на сложность программы каждой функциональной группы. По мнению автора метрики, наибольший вес, равный 3, имеет функциональная группа C, так как она влияет на поток управления программы. Весовые коэффициенты остальных групп распределяются следующим образом : a1=1, a2=2, a4=0.5. Весовой коэффициент группы T не равен 0, поскольку «паразитные» переменные не увеличивают сложность потока данных программы, но иногда затрудняют ее понимание. С учетом весовых коэффициентов:
Отношение числа фактических обращений к возможным определяется
Эта формула показывает приближенную вероятность ссылки произвольного модуля на произвольную глобальную переменную. Очевидно, что чем выше эта вероятность, тем выше вероятность «несанкционированного» изменения какой-либо переменной, что может существенно осложнить работы, связанные с модификацией программы.
На основе концепции информационных потоков создана мера Кафура. Для использования данной меры вводятся понятия локального и глобального потока: локальный поток информации из A в B существует, если:
1. Модуль А вызывает модуль В (прямой локальный поток)
2. Модуль В вызывает модуль А и А возвращает В значение, которое используется в В (непрямой локальный поток)
3. Модуль С вызывает модули А, В и передаёт результат выполнения модуля А в В.
Далее следует дать понятие глобального потока информации: глобальный поток информации из А в В через глобальную структуру данных D существует, если модуль А помещает информацию в D, а модуль В использует информацию из D.
Можно определить информационную сложность модуля как сумму информационных сложностей входящих в него процедур.
Автор метрики исходит из следующих предположений:программист может найти отношение между определяющими и использующими вхождениями переменной внутри луча более легко, чем между лучами; число различных определяющих вхождений в каждом луче более важно, чем общее число использующих вхождений переменных в каждом луче.
Обозначим через R(i) множество определяющих вхождений переменных, которые расположены в радиусе действия луча i (определяющее вхождение переменной находится в радиусе действия луча, если переменная либо локальна в нём и имеет определяющее вхождение, либо для неё есть определяющее вхождение в некотором предшествующем луче, и нет локального определения по пути). Обозначим через V(i) множество переменных, использующие вхождения которых уже есть в луче i. Тогда мера сложности i-го луча задаётся как:
DF(i)=СУММА(DEF(vj)), j=i. ||V(i)||
4. Метрики сложности потока управления и данных программы
Первой из таких метрик является тестирующая М-Мера [4]. Тестирующей мерой М называется мера сложности, удовлетворяющая следующим условиям:
Мера возрастает с глубиной вложенности и учитывает протяженность программы. К тестирующей мере близко примыкает мера на основе регулярных вложений. Идея этой меры сложности программ состоит в подсчете суммарного числа символов (операндов, операторов, скобок) в регулярном выражении с минимально необходимым числом скобок, описывающим управляющий граф программы. Все меры этой группы чувствительны к вложенности управляющих конструкций и к протяженности программы. Однако возрастает уровень трудоемкости вычислений.
Также мерой качества программного обеспечения служит связанность модулей программы [5]. Если модули сильно связанны, то программа становится трудномодифицируемой и тяжелой в понимании. Данная мера не выражается численно. Виды связанности модулей:
Модули связаны по общей области в том случае, если они ссылаются на одну и туже область глобальных данных. Связанность (сцепление) по общей области является нежелательным, так как, во-первых, ошибка в модуле, использующем глобальную область, может неожиданно проявиться в любом другом модуле; во-вторых, такие программы трудны для понимания, так как программисту трудно определить какие именно данные используются конкретным модулем.
1. Для каждой управляющей переменной i вычисляется значениt её сложностной функции C(i) по формуле: C(i) = (D(i) * J(i))/n.
3. Общая сложность MP иерархической схемы разбиения программы на модули задаётся формулой:
Данная метрика ориентирована на программы, хорошо структурированные, составленные из иерархических модулей, задающих функциональную спецификацию и структуру управления. Также подразумевается, что в каждом модуле одна точка входа и одна точка выхода, модуль выполняет ровно одну функцию, а вызов модулей осуществляется в соответствии с иерархической системой управления, которая задаёт отношение вызова на множестве модулей программы.
Недостатком данной метрики является то, что программа, содержащая много уникальных символов, но в малом количестве, будет иметь такую же сложность как программа, содержащая малое количество уникальных символов, но в большом количестве.
5. Объектно-ориентированные метрики
В связи с развитием объектно-ориентированных языков программирования появился новый класс метрик, также называемый объектно-ориентированными метриками. В данной группе наиболее часто используемыми являются наборы метрик Мартина и набор метрик Чидамбера и Кемерера. Для начала рассмотрим первую подгруппу.
Прежде чем начать рассмотрение метрик Мартина необходимо ввести понятие категории классов. В реальности класс может достаточно редко быть повторно использован изолированно от других классов. Практически каждый класс имеет группу классов, с которыми он работает в кооперации, и от которых он не может быть легко отделен. Для повторного использования таких классов необходимо повторно использовать всю группу классов. Такая группа классов сильно связна и называется категорией классов. Для существования категории классов существуют следующие условия:
Классы в пределах категории класса закрыты от любых попыток изменения все вместе. Это означает, что, если один класс должен измениться, все классы в этой категории с большой вероятностью изменятся. Если любой из классов открыт для некоторой разновидности изменений, они все открыты для такой разновидности изменений.
Классы в категории повторно используются только вместе. Они настолько взаимозависимы и не могут быть отделены друг от друга. Таким образом, если делается любая попытка повторного использования одного класса в категории, все другие классы должны повторно использоваться с ним.
Классы в категории разделяют некоторую общую функцию или достигают некоторой общей цели.
Ответственность, независимость и стабильность категории могут быть измерены путем подсчета зависимостей, которые взаимодействуют с этой категорией. Могут быть определены три метрики :
1. Ca :Центростремительное сцепление. Количество классов вне этой категории, которые зависят от классов внутри этой категории.
2. Ce: Центробежное сцепление. Количество классов внутри этой категории, которые зависят от классов вне этой категории.
3. I: Нестабильность: I = Ce / (Ca+Ce). Эта метрика имеет диапазон значений [0,1].
I = 0 указывает максимально стабильную категорию.
I = 1 указывает максимально не стабильную категорию.
Можно определять метрику, которая измеряет абстрактность (если категория абстрактна, то она достаточно гибкая и может быть легко расширена) категории следующим образом:
A: Абстрактность: A = nA / nAll.
Значения этой метрики меняются в диапазоне [0,1].
0 = категория полностью конкретна,
1 = категория полностью абстрактна.
Теперь на основе приведенных метрик Мартина можно построить график, на котором отражена зависимость между абстрактностью и нестабильностью. Если на нем построить прямую, задаваемую формулой I+A=1, то на этой прямой будут лежать категории, имеющие наилучшую сбалансированность между абстрактностью и нестабильностью. Эта прямая называется главной последовательностью.
Далее можно ввести еще 2 метрики:
Расстояние до главной последовательности: D=|(A+I-1)/sqrt(2)|
Нормализированной расстояние до главной последовательности: Dn=|A+I-2|
Практически для любых категорий верно то, что чем ближе они находятся к главной последовательности, тем лучше.
6. Метрики надежности
7. Гибридные метрики
В завершении необходимо упомянуть еще один класс метрик, называемых гибридными. Метрики данного класса основываются на более простых метриках и представляют собой их взвешенную сумму. Первым представителем данного класса является метрика Кокола. Она определяется следующим образом:
Функции M(Mi) и коэффициенты Ri вычисляются с помощью регрессионного анализа или анализа задачи для конкретной программы.
В результате исследований, автор метрики выделил три модели для мер: Маккейба, Холстеда и SLOC, где в качестве базовой используется мера Холстеда. Эти модели получили название «наилучшая», «случайная» и «линейная».
Метрика Зольновского, Симмонса, Тейера также представляет собой взвешенную сумму различных индикаторов. Существуют два варианта данной метрики:
(структура, взаимодействие, объем, данные) СУММА(a, b, c, d).
(сложность интерфейса, вычислительная сложность, сложность ввода/вывода, читабельность) СУММА(x, y, z, p).