Метрики Кода И Их Практическая Реализация В Subversion И Clearcase. Часть 1 - Метрики

Метрики кода и их практическая реализация в Subversion и ClearCase. Часть 1 - метрики

Аудитория: менеджеры проектов, разработчики, тестировщики, руководители, аналитики
Авторы: Новичков Александр, Шамрай Александр, Черников Алексей

Оглавление

1 Введение

2 Метрики.

2.1 Размерно-ориентированные метрики (показатели оценки объема)

2.1.1 LOC-оценка (Lines Of Code)

2.1.1.1 Метрика стилистики и понятности программ..

2.1.2 Итого по SLOC..

2.2 Метрики сложности.

2.2.1 Объектно-ориентированные метрики.

2.2.2 Метрики Холстеда.

2.2.3 Метрики цикломатической сложности по Мак-Кейбу. 9

2.2.4 Метрики Чепина.

2.3 Предварительная оценка на основе статистических методов в зависимости от этапов разработки программы..

2.3.1 Предварительная оценка сложности программы на этапе разработки спецификации требований к программе.

2.3.2 Предварительная оценка сложности на этапе определения архитектуры

2.4 Общий списочный состав метрик

2.4 Подведение итогов.

6 Ресурсы интернет.

1. Введение

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

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

Современные комплексные системы оценки характеристик проектов создания ПО могут быть использованы для решения следующих задач:

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

2. Метрики

Метрики сложности программ принято разделять на три основные группы:

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

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

Метрики второй группы базируются на анализе управляющего графа программы. Представителем данной группы является метрика Маккейба.

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

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

2.1 Размерно - ориентированные метрики (показатели оценки объема)

2.1.1 LOC-оценка (Lines Of Code)

Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются такие метрики на LOC-оценках.

Этот вид метрик косвенно измеряет программный продукт и процесс его разработки. Вместо подсчета 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 не отражает трудоемкости по созданию программы .

Пример из жизни :
В одной из компаний при внедрении мы применили данную метрику - считали строки кода. Руководитель организации был в отпуске, но по возвращении из него решил воспользоваться прозрачностью и трассируемостью изменений и посмотреть, как же идут дела в проектах у его менеджеров. И чтоб полностью войти в курс, опустился на самый низкий уровень (то есть не стал оценивать плотность дефектов, количество исправленных багов) - на уровень исходных текстов. Решил посчитать, кто и сколько строк написал. А чтоб было совсем весело - соотнести количество рабочих дней в неделю и количество написанного кода (логика проста: человек работал 40 часов в неделю, значит, должен много чего написать). Естественно, нашелся человек, который за неделю написал всего одну строку, даже не написал, а только откорректировал существующую...

Гневу руководителя не было предела - нашел бездельника! И плохо было бы программисту, если бы менеджер проекта не объяснил, что: была найдена ошибка в программе, нашел ее VIP - клиент, ошибка влияет на бизнес клиента и ее нужно было срочно устранить, для этого был выбран вот этот конкретный исполнитель, который развернул стенд, залил среду клиента, подтвердил проявление ошибки и начал ее искать и устранять. Естественно, в конце концов, он поменял фрагмент кода, в котором было неправильное условие и все заработало.

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

2.2 Метрики сложности

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

2.2.1 Объектно-ориентированные метрики

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

МетрикаОписание Взвешенная насыщенность класса 1 (Weighted Methods Per Class (WMC) Отражает относительную меру сложности класса на основе цикломатической сложности каждого его метода. Класс с более сложными методами и большим количеством методов считается более сложным. При вычислении метрики родительские классы не учитываются. Взвешенная насыщенность класса 2 (Weighted Methods Per Class (WMC2)) Мера сложности класса, основанная на том, что класс с большим числом методов, является более сложным, и что метод с большим количеством параметров также является более сложным. При вычислении метрики родительские классы не учитываются. Глубина дерева наследования (Depth of inheritance tree) Длина самого длинного пути наследования, заканчивающегося на данном модуле. Чем глубже дерево наследования модуля, тем может оказаться сложнее предсказать его поведение. С другой стороны, Увеличение глубины даёт больший потенциал повторного использования данным модулем поведения, определённого для классов-предков. Количество детей (Number of children) Число модулей, непосредственно наследующих данный модуль.Большие значения этой метрики указывают на широкие возможности повторного использования; при этом слишком большое значение может свидетельствовать о плохо выбранной абстракции. Связность объектов (Coupling between objects)Количество модулей, связанных с данным модулем в роли клиента или поставщика. Чрезмерная связность говорит о слабости модульной инкапсуляции и может препятствовать повторному использованию кода. Отклик на класс (Response For Class) Количество методов, которые могут вызываться экземплярами класса; вычисляется как сумма количества локальных методов, так и количества удаленных методов

2.2.2 Метрики Холстеда

Метрика Холстеда относится к метрикам, вычисляемым на основании анализа числа строк и синтаксических элементов исходного кода программы.

Основу метрики Холстеда составляют четыре измеряемые характеристики программы:

NUOprtr (Number of Unique Operators) - число уникальных операторов программы, включая символы-разделители, имена процедур и знаки операций (словарь операторов); NUOprnd (Number of Unique Operands) - число уникальных операндов программы (словарь операндов); Noprtr (Number of Operators) - общее число операторов в программе; Noprnd (Number of Operands) - общее число операндов в программе.

На основании этих характеристик рассчитываются оценки:

Словарь программы (Halstead Program Vocabulary, HPVoc): HPVoc = NUOprtr + NUOprnd; Длина программы (Halstead Program Length, HPLen): HPLen = Noprtr + Noprnd; Объем программы (Halstead Program Volume, HPVol): HPVol = HPLen log2 HPVoc; Сложность программы (Halstead Difficulty, HDiff): HDiff = (NUOprtr/2) ? (NOprnd / NUOprnd); На основе показателя HDiff предлагается оценивать усилия программиста при разработке при помощи показателя HEff (Halstead Effort): HEff = HDiff? HPVol.

2.2.3 Метрики цикломатической сложности по Мак-Кейбу

Показатель цикломатической сложности является одним из наиболее распространенных показателей оценки сложности программных проектов. Данный показатель был разработан ученым Мак-Кейбом в 1976 г., относится к группе показателей оценки сложности потока управления программой и вычисляется на основе графа управляющей логики программы (control flow graph). Данный граф строится в виде ориентированного графа, в котором вычислительные операторы или выражения представляются в виде узлов, а передача управления между узлами - в виде дуг.

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

Упрощенная формула вычисления цикломатической сложности представляется следующим образом:

C = e - n + 2,

Где e - число ребер, а n - число узлов на графе управляющей логики.

Как правило, при вычислении цикломатической сложности логические операторы не учитываются.

В процессе автоматизированного вычисления показателя цикломатической сложности, как правило, применяется упрощенный подход, в соответствии с которым построение графа не осуществляется, а вычисление показателя производится на основании подсчета числа операторов управляющей логики (if, switch и т. д.) и возможного количества путей исполнения программы.

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

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

Существует значительное количество модификаций показателя цикломатической сложности.

«Модифицированная» цикломатическая сложность - рассматривает не каждое ветвление оператора множественного выбора (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 содержит краткое описание метрик, не вошедших в детальное описание выше, но тем не менее даные метрики нужны и важны, просто по статистике они встречаются гораздо реже.

Также отметим, что цель этой статьи показать принцип, а не описать все возможные метрики во множестве комбинаций.

Таблица 1 - Состав метрик их влияние и анализ эффективности использования

Наименование метрики

Описание краткое

Описание детальное

Класс или тип метрики

Метрика Майерса

Интервальная мера

Сложность программ определяется в виде отрезка
[Z(G), Z(G)+h], где
Z(G) - метрика Маккейба,
H = n - 1, для n-местного предиката и
H = 0, для простого предиката

Топологическая

Метрика Джилба

Логическая сложность программы определяется как насыщенность программы выражениями типа IF-THEN-ELSE. При этом вводятся две характеристики: CL - абсолютная сложность программы, характеризующаяся количеством операторов условия; cl - относительная сложность программы, характеризующаяся насыщенностью программы операторами условия, т. е. cl определяется как отношение CL к общему числу операторов:

Количество операторов цикла; Количество операторов условия; Число модулей или подсистем; Отношение числа связей между модулями к числу модулей; Отношение числа ненормальных выходов из множества операторов к общему числу операторов.

Топологическая

Метрика Хансена

Пара (цикломатическое число, число операторов)

(A, B), где A - метрика Маккейба, B - число исполняемых операторов.

Топологическая

Метрика Чена

Топологическая метрика Чена

M(G) = (n (G), N, Q0)

Топологическая

Метрика Вудворда

Узловая мера (число узлов передач управления)

На полях листинга рисуются линии передачи управления от одного оператора к другому (предполагается, что один оператор занимает ровно одну строчку). Число пересечений этих линий даёт значений метрики.

Топологическая

Метрики Харрисона, Мейджела

Функциональное число (сумма приведенных сложностей всех вершин управляющего графа);
Функциональное отношение (отношение числа вершин графа к функциональному числу);
Регулярные выражения (число операндов, операторов и скобок в регулярном выражении управляющего графа программы)

Данная мера учитывает уровень вложенности и протяженность программы.

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

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

Функциональная мера (SCOPE) программы -- это сумма приведенных сложностей всех вершин управляющего графа.

Функциональным отношением (SCORT) называется отношение числа вер­шин в управляющем графе к его функциональной сложности, причем из числа вершин исключаются терминальные.

SCORT принимает разные значения для графов с одинаковым цякломатиче-ским числом.

Топологическая

Метрика Пивоварского

Модифицированная цикломатическая мера сложности

Мера Пивоварского ставит целью учесть в оценке сложности ПС различия не только между последовательными и вложенными уп­равляющими конструкциями, но и между структурированными и неструктурированными программами. Она выражается отношением N(G) = v*(G) + ? Pt, где v*(G) - модифицированная цикломатичес-кая сложность, вычисленная так же, как и V(G), но с одним отли­чием: оператор CASE с я-выходами рассматривается как один логи­ческий оператор, а не как п-1 оператор, Р1 - глубина вложенности i-й предикатной вершины.

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

Топологическая

Метрика Мак-Клура

Мера сложности, основанная на числе возможных путей выполнения программы, числе управляющих конструкций и переменных;

Выделяются три этапа вычисления данной метрики:

1) Для каждой управляющей переменной i вычисляется значения её сложностной функции C(i) по формуле:
C(i) = (D(i) * J(i))/n
Где D(i) - величина, измеряющая сферу действия переменной i. J(i) - мера сложности взаимодействия модулей через переменную i, n - число отдельных модулей в схеме разбиения.

2) Для всех модулей, входящих в сферу разбиения, определяется значение их сложностных функций M(P) по формуле
M(P) = fp * X(P) + gp * Y(P)
Где fp и gp - соответственно число модулей, непосредственно предшествующих и непосредственно следующих за модулем P, X(P) - сложность обращения к модулю P, Y(P) - сложность управления вызовом из модуля P других модулей.

3) Общая сложность MP иерархической схемы разбиения программы на модули задаётся формулой
MP = {Сумма по всем возможным значениям P - модулям программы} (M(P))

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

Метрика, направленная на измерение архитектуры системы

Метрика Кафура

Вводятся понятия локального и глобального потока:
Локальный поток информации из A в B существует, если:

Модуль А вызывает модуль В (прямой локальный поток) Модуль В вызывает модуль А и А возвращает В значение, которое используется в В (непрямой локальный поток) Модуль С вызывает модули А, В и передаёт результат выполнения модуля А в В

Глобальный поток информации из А в В через глобальную структуру данных D существует, если
Модуль А помещает информацию в D, а модуль В использует информацию из D.

На основе этих понятий вводится величина I - информационная сложность процедуры:
I = length * (fan_in * fan_out)^2

Здесь:

length - сложность текста процедуры (меряется через какую-нибудь из метрик объёма, типа метрик Холстеда, Маккейба, LOC и т. п.) fan_in - число локальных потоков внутрь процедуры плюс число структур данных, из которых процедура берёт информацию fan_out - число локальных потоков из процедуры плюс число структур данных, которые обновляются процедурой

Можно определить информационную сложность модуля как сумму информационных сложностей входящих в него процедур.

Следующий шаг - рассмотреть информационную сложность модуля относительно некоторой структуры данных. Информационная мера сложности модуля относительно структуры данных:

J = W * R + W * WrRd + WrRd x R + WrRd * (WrRd - 1)

Здесь:

W - число процедур, которые только обновляют структуру данных; R - Только читают информацию из структуры данных; WrRd - и читают, и обновляют информацию в структуре данных.

Метрика, основанная на учёте потока данных

Метрика Зольновского, Симмонса, Тейера

Взвешенная сумма различных индикаторов

(структура, взаимодействие, объем, данные)
(сложность интерфейса, вычислительная сложность, сложность ввода/вывода, читабельность)

Гибридная

Метрика Янгера

Сложность проектирования
Насыщенность комментариями
Число внешних обращений
Число операторов

Логическая сложность с учетом истории вычислений

Топологическая

Метрика 'Подсчет точек пересечения'

Поток управления программы считается более сложным, если возникают точки пересечения дуг передачи управления.

В графе программы, где каждому оператору соответствует вершина, т. е. не исключены линейные участки, при передаче управления от вершины a к b номер оператора a равен min(a, b), а номер оператора b - max(a, b). Точка пересечения дуг появляется, если

Min(a, b) < min(p, q) < max(a, b) & max(p, q) > max(a, b) |
Min(a, b) < max(p, q) < max(a, b) & min(p, q) < min(a, b).

Иными словами, точка пересечения дуг возникает в случае выхода управления за пределы пары вершин (a, b).

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

Метрика сложности потока управления программ

Метрика граничных значений

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

Пусть G=(V, E) - ориентированный граф программы. Число входящих вершин у дуг называется отрицательной степенью вершины, а число исходящих из вершины дуг - положительной степенью вершины. Вершины у которых положительная степень <=1 назовем принимающими вершинами, а вершины у которых положительная степень >=2 вершинами отбора.

Для получения оценки по методу граничных значений необходимо разбить граф G на максимальное число подграфов G', удовлетворяющих следующим условиям : вход в подграф осуществляется только через вершину отбора; каждый подграф включает вершину (называемую в дальнейшем нижней границей подграфа), в которую можно попасть из любой другой вершины подграфа.

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

S0=1-(v-1)/Sa,

Где S0 - относительная граничная сложность программы; Sa - абсолютная граничная сложность программы; v - общее число вершин графа программы.

Метрика сложности потока управления программ

Метрика обращения к глобальным переменным

Пара (модуль, глобальная переменная) (фактическая/возможная)
Aup, Pup, Rup

Пара "модуль-глобальная переменная" обозначается как (p, r), где p - модуль, имеющий доступ к глобальной переменной r. В зависимости от наличия в программе реального обращения к переменной r формируются два типа пар "модуль-глобальная переменная" : фактические и возможные. Возможное обращение к r с помощью p показывает, что область существования r включает в себя p.

Характеристика Aup говорит о том, сколько раз модули Up действительно получали доступ к глобальным переменным, а число Pup - сколько раз они могли бы получить доступ.

Отношение числа фактических обращений к возможным определяется

Rup = Aup/Pup.

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

Метрика сложности потока данных

Метрика спена

Определение спена основывается на локализации обращений к данным внутри каждой программной секции.

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

Метрика сложности потока данных

Набор метрик Чидамбера и Кемерера (WMC, DIT, NOC, CBO, RFC, LCOM)

Вводится ряд метрик, в сумме дающие представление о сложности ОО-кода.

WMC - Weighted methods per class (вычисляется сложность методов каким-либо способом и берётся сумма сложностей)
DIT - Depth of Inheritance Tree (глубина дерева наследования)
NOC - Number of Children (число потомков)
CBO - Coupling between objects (связность между объектами)
RFC - Response For a Class
LCOM - Lack of Cohesion in Methods (нехватка сцепления методов)

Метрика для ООП программ

Связность

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

Content coupling (связность по содержимому)
Common coupling (совместная связность)
External coupling (внешняя связность)
Control coupling (связность управления)
Stamp coupling (Data-structured coupling)
Data coupling (связность данных)
Message coupling (low)
No coupling (отсутствие связности)
Subclass Coupling (связность подклассов)
Temporal coupling (связность по времени)

Топологическая

Характеристический полином PCN

Вычисляется сложность с учётом циклической ст