3. Объектно-ориентированные метрики для измерения

Анализ программного обеспечения
с использованием объектно-ориентированных метрик
Валентин Павлов
Введение .............................................................................................................................2
Метрические особенности объектно-ориентированных программных систем ..........2
2.1
Локализация ...............................................................................................................2
2.2
Инкапсуляция.............................................................................................................3
2.3
Информационная закрытость ...................................................................................3
2.4
Наследование .............................................................................................................3
2.5
Абстракция .................................................................................................................3
3. Объектно-ориентированные метрики для измерения характеристик систем .............4
3.1
Количество строчек кода (LOC) ..............................................................................4
3.2
Цикломатическая сложность Мак-Кейба (MVG) ...................................................4
3.3
Количество комментариев (COM) ...........................................................................5
3.4
Число классов – получателей сообщений данного класса (Fan-out, Fan-in) ........5
3.5
Количество "взвешенных" методов на класс (WMC) ............................................5
3.6
Глубина дерева наследования (DIT) ........................................................................6
3.7
Количество потомков (NOC) ....................................................................................6
3.8
Ширина иерархии наследования (BIH) ...................................................................7
3.9
Глубина класса в графе наследования (NL) ...........................................................7
3.10 Связанность между классами объектов (CBO) .......................................................7
3.11 Количество реакций на класс (RFC) ........................................................................8
3.12 Отсутствие сцепления в методах (LCOM) ..............................................................9
3.13 Количество строк текста на класс (KLOC) ...........................................................10
3.14 Число методов в классе (NM).................................................................................10
3.15 Число новых методов в классе (NNM) ..................................................................10
3.16 Количество унаследованных методов (NMI) ........................................................11
3.17 Количество потенциально наследуемых методов (PMI) .....................................11
3.18 Пропорция методов наследуемых подклассом (PMIS)........................................11
3.19 Число общедоступных методов в классе (NPM) ..................................................12
3.20 Степень методологической сцепленности (DMC) ...............................................12
3.21 Количество посылаемых методом сообщений (NMS) .........................................13
3.22 Сообщения и аргументы (MAA) ............................................................................13
3.23 Количество абстрактных классов (NAC) ..............................................................15
3.24 Степень абстрактности классов (DAC) .................................................................15
3.25 Количество переопределеных методов в подклассе (NMO) ...............................15
3.26 Пропорция переопределения методов в подклассе (POM) .................................16
3.27 Число свойств (атрибутов или переменных) в классе(NAA) ..............................16
3.28 Число унаследованных свойств (атрибутов или переменных) в классе (NIV) .16
3.29 Использование глобалов (GUS) .............................................................................16
3.30 Излишняя взаимосвязь через глобалы (UCGU)....................................................17
3.31 Степень взаимосвязи между классами (DCBO) ...................................................17
3.32 Количество скрытых методов экземпляра (PrIM) ................................................17
3.33 Мера Мак-Клура (MMK) ........................................................................................17
4. Литература .......................................................................................................................17
1.
2.
1
1. Введение
Разработка сложных систем на объектно-ориентированных языках программирования
требует постоянного принятия решений, которые существенно влияют на успешность
завершения проекта. Возможность оценить последствия принятия таких решений на
возможно более ранних этапах разработки системы может упростить и ускорить работу
над проектом. Особенно важно наличие критериев оценки принимаемых решений, а также
возможность выразить эти оценки количественно. В этом случае имеется возможность
оценить, какие характеристики системы улучшаются в результате принятия какого либо
решения, а какие ухудшаются. Таким образом разрабатываемую систему можно
"измерить". Количественные критерии оценки в этом случае называются метриками.
Еще большее значение имеют метрики при сопровождении программных систем.
Поскольку зачастую сопровождать систему должна группа людей, которая не занималась
разработкой этой системы. Проанализировать и оценить полученную для сопровождения
систему, найдя в ней достоинства и недостатки довольно сложно. Еще сложнее начать
вносить существенные изменения в такую систему, дополняя ее новыми возможностями.
Сложные системы чаще всего разработаны на объектно-ориентированных языках
программирования. Поэтому метрики для оценки характеристик также должны
использовать понятия объектно-ориентированных языков программирования.
Даже наличие метрик, адекватно отражающих свойства системы, и наличие методик их
применения, не позволяют в полной мере ими воспользоваться. Объем разрабатываемых
или сопровождаемых систем не позволит корректно использовать метрики и методики
вручную. Весьма сложно измерять что либо, визуально просматривая тысячи строк текста
программ. Это требует также весьма высокой квалификации в области объектноориентированных языков программирования. Склонность человека ошибаться, а также
влияние на такую работу психологических факторов делает бессмысленным измерение
характеристик системы без наличия специализированных инструментов.
Анализ программных систем с помощью специализированного инструмента требует
адекватного представления этим инструментом понятий используемого языка
программирования. По сложности этот инструмент сопоставим с компилятором для
используемого при разработке системы языка программирования. Оптимальным
решением поэтому является встраивание средств анализа и измерения характеристик
системы в сам компилятор.
2. Метрические особенности объектно-ориентированных
программных систем
Объектно-ориентированные метрики вводятся с целью:
 Улучшить понимание качества продукта;
 Оценить эффективность процесса конструирования;
 Улучшить качество работы на этапе проектирования;
С точки зрения метрик выделяют пять характеристик объектно-ориентированных систем:
локализацию, инкапсуляцию, информационную закрытость, наследование и способы
абстрагирования объектов. Эти характеристики оказывают максимальное влияние на
объектно-ориентированные метрики.
2.1
Локализация
Локализация фиксирует способ группировки информации в программе. В классических
методах, где используется функциональная декомпозиция, информация локализуется
вокруг функций. Функции в них реализуются как процедурные модули. В методах,
2
управляемых данными, информация группируется вокруг структур данных. В объектноориентированной среде информация группируется внутри классов или объектов
(инкапсуляцией как данных так и процессов). Поскольку в классических методах
основной механизм локализации – функция, программные метрики ориентированы на
внутреннюю структуру или сложность функций (длина модуля, связность,
цикломатическая сложность) или на способ, которым функции связываются друг с другом
(сцепление модулей). Так как в объектно-ориентированной системе базовым элементом
является класс, то локализация здесь основывается на объектах. Поэтому метрики должны
применяться к классу (объекту) как к комплексной сущности. Кроме того, между
операциями (функциями) и классами могут быть отношения не только “один-к-одному”.
Поэтому метрики, отображающие способы взаимодействия классов, должны быть
приспособлены к отношениям “однин-ко-многим”, “многие-ко-многим”.
2.2
Инкапсуляция
Для классических ПС примерами низкоуровневой инкапсуляции являются записи и
массивы. Механизмом инкапсуляции среднего уровня являются подпрограммы
(процедуры, функции). В объектно-ориентированных системах инкапсулируются
обязанности класса, представляемые его свойствами, операциями и состояниями.
Для метрик учет инкапсуляции приводит к смещению фокуса измерений с одного модуля
на группу свойств о обрабатывающих модулей (операций). Кроме того, инкапсуляция
переводит измерения на более высокий уровень абстракции (пример – метрика
“количество операций на класс”). Напротив, классические меры ориентированы на низкий
уровень – количество булевых условий (цикломатическая сложность) и количество строк
программы.
2.3
Информационная закрытость
Информационная закрытость делает невидимыми операционные детали программного
компонента. Другим компонентам доступна только необходимая информация.
Качественные объектно-ориентированные системы поддерживают высокий уровень
информационной закрытости. Таким образом, метрики, измеряющие степень достигнутой
информационной закрытости, тем самым отображают качество объектноориентированного проекта.
2.4
Наследование
Стандартные ПС не поддерживают эту характеристику, так как она распространяется
через уровни иерархии программных компонентов, обеспечивая тиражирование
обязанностей одного класса в другие класса. Поскольку наследование – основная
характеристика объектно-ориентированных систем, на ней фокусируются многие
объектно-ориентированные метрики (количество детей – потомков класса, количество
родителей, высота класса в иерархии наследования).
2.5
Абстракция
Абстракция – это механизм, который позволяет проектировщику выделять главное в
программном компоненте (как свойства, так и операции) без учета второстепенных
деталей. По мере помещения на более высокие уровни абстракции игнорируются все
большее количество деталей, обеспечивая все более общее представление понятия или
элемента. Класс – это абстракция, которая может быть представлена на различных
уровнях детализации и различными способами (например как список операций,
последовательность состояний, последовательность взаимодействий). Поэтому объектноориентированные метрики должны представлять абстракции в терминах измерений
класса. Примеры: количество экземпляров класса в приложении, количество родовых
классов на приложение, отношение количества родовых к количеству неродовых.
3
3. Объектно-ориентированные метрики для измерения
характеристик систем
Метрики для измерения характеристик программных систем тесно связаны с понятиями
языка, на котором он были созданы. Поскольку при разработке и сопровождении системы
необходимо будет оперировать этими понятиями, метрики должны позволять измерить
эти понятия. Далее в этом разделе рассматриваются метрики для объектноориентированных языков программирования. Описываемые метрики часто используются
в статьях и книгах соответствующей тематики. Для многих из них имеются общепринятые
названия и их сокращения. Поэтому для метрик будет приводится также соответствующее
название и сокращение на английском языке.
3.1
Количество строчек кода (LOC)
Метрика (Lines of Сode) для подсчета исполняемых строчек кода. Метрика позволяет
измерить не пустые и не закомментированные строчки кода. Может существовать
несколько вариаций: LOCf - количество строчек кода в функциях, LOCm – в модулях
(при ОО проектировании – модуль = класс), или LOCp – количество строк кода во всем
проекте. Эта метрика одна из первых и наиболее часто используемых, так как, опираясь
на нее, можно получить грубую оценку об изменениях в проекте.
Подсчитывается, опираясь на стандарт подсчета исполняемых строк кода, т.е.
подсчитываются не пустые, не комментированные строки. Строчки препроцессора
считаются как пустые. Определения классов и функций считаются за исключением
глобальных определений.
3.2
Цикломатическая сложность Мак-Кейба (MVG)
Топологическая мера сложности - цикломатическая мера Мак-Кейба. В ее основе лежит
идея оценки сложности ПО по числу базисных путей в ее управляющем графе, т.е. таких
путей, компонуя которые можно получить всевозможные пути из входа графа в выходы.
Цикломатическое число l (G) орграфа G с n-вершинами, m-дугами и p-компонентами
связности есть величина l (G) = m - n + p.
Существует теорема о том, что число базисных путей в орграфе равно его
цикломатическому числу, увеличенному на единицу. При этом, цикломатической
сложностью ПО Р с управляющим графом G называется величина n (G) = l (G) +1 = m - n
+ 2. Практически цикломатическая сложность ПО равна числу предикатов плюс единица,
что позволяет вычислять ее без построения управляющего графа простым подсчетом
предикатов. Данная мера отражает психологическую сложность ПО. К достоинствам меры
относят простоту ее вычисления и повторяемость результата, а также наглядность и
содержательность интерпретации. В качестве недостатков можно отметить:
нечувствительность к размеру ПО, нечувствительность к изменению структуры ПО,
отсутствие корреляции со структурированностью ПО, отсутствие различия между
конструкциями Развилка и Цикл, отсутствие чувствительности к вложенности циклов.
Формальное определение цикломатической сложности – это подсчет линейно
независимых частей в графе потока управления полученного из программы. Примерное
приближение может быть получено путем подсчета ключевых слов языка и операторов.
Можно показать, что это будет достаточно точное приближение во многих случаях. В
случае С++ подсчет идет по следующим маркерам - 'if', 'while', 'for', 'switch', 'break', '&&',
'||'. Необходимо обратить внимание, что булевские операторы добавляют дополнительные
ветвления в код, при том что не все булевское выражение может быть выполнено в
зависимости от составляющих частей операнда. Кроме того, обработка switch оператора
достаточно проблематично: не все case могут указывать на один блок кода, следовательно,
подсчет таких операторов может немного завысить итоговое значение.
4
3.3
Количество комментариев (COM)
Метрика для подсчета комментированных строчек кода(Comment Lines). Это грубая мера
сравнимая с LOC показывающая объем комментариев внутри региона кода. Подобную
меру достаточно сложно использовать отдельно от LOC, но при использовании
отношений к LOC или MVG подобный коэффициент покажет пропорциональное
отношение комментариев к исполняемому коду или его сложности. L_C = LOC/COM;
M_C = MVG/COM.
3.4
Число классов – получателей сообщений данного класса
(Fan-out, Fan-in)
Число классов – получателей сообщений данного класса (Fan-out, the number of other
collaborating classes irrespective of the number of references) - число дуг в простейшей
модели передачи сообщений, выходящих из вершины, соответствующей классу, т.е. число
классов, к методам которых есть обращения в методах данного класса.
Для заданного модуля А, метрика Fan-out покажет количество классов которые
используют модуль А, тогда как метрика Fan-in покажет количество модулей которое
использует модуль А. Определение Fan-in - число вершин, из которых входят дуги в
данную вершину в простейшей модели взаимодействия компонентов
3.5
Количество "взвешенных" методов на класс (WMC)
Количество взвешенных методов на класс (Weighted Methods Per Class - WMC) позволяет
измерять сложность классов с учетом сложности его методов. Весом метода в этом случае
называется количественная характеристика (метрика) сложности метода.
Рассмотрим простейший случай, когда сложность метода определяется количеством строк
текста этого метода в программе. Пусть L[i] - это количество строк текста у метода с
номером i, а всего в классе n методов. Тогда для этой метрики измерения методов
сложность класса Point вычисляется следующим образом:
WMC(Point) = L[0] + ... + L[n]
Как можно заметить, метрика WMC для измерения сложности класса зависит от способа
измерения сложности методов этого класса.
Часто используется разновидность метрики WMC, когда все методы имеют одинаковый
вес. Она называется "Количество методов на класс" (Number of Methods - NM).
Используется метрика NM для измерения сложности классов на ранних этапах разработки
системы, когда еще нет детальной информации о методах. Возможно, что класс со
слишком большим количеством методов на этапе проектирования системы следует
разделить на несколько классов.
Вероятное влияние метрики на характеристики системы:
 С помощью метрики WMC можно оценить сложность класса. Это позволит
оценить, сколько времени и усилий необходимо будет затратить его на разработку
и сопровождение учитывая сложность его методов.
 Большое количество методов базового класса потенциально распространяет свое
влияние и на потомков этого класса. Поскольку все потомки наследуют все методы
этого класса, то усложнение методов базового класса может отразится на потомках
класса.
 Классы с большим числом методов с большой долей вероятности специфичны для
приложения. Поэтому скорее всего они будут менее пригодны для повторного
использования в других приложениях.
5
Метрика связана с сопровождаемостью программ, поскольку, чем больше число методов и
выше их сложность, тем выше затраты на проектирование, кодирование, испытания и
сопровождение класса
3.6
Глубина дерева наследования (DIT)
Глубина дерева наследования (Depth of Inheritance Tree - DIT) позволяет определить
количество классов-предков, которые потенциально оказывают влияние на данный класс.
Вероятное влияние метрики DIT на характеристики системы:
 Большое количество предков делает поведение класса менее предсказуемым.
 Глубокие деревья наследования усложняют проект, поскольку включают большее
число атрибутов и методов в классах-потомках.
 Чем глубже положение класса в дереве иерархии, тем больше повторное
использование его методов.
Глубина класса в дереве наследования – длина пути в простейшей модели иерархии
наследования классов от корня до вершины, соответствующей рассматриваемому классу.
Шкала значений абсолютная.
Данное определение справедливо только для ОО проектов и программ, модель иерархии
наследования которых представляет собой дерево. В литературе, как правило, не
рекомендуется проектировать классы, наследующие свойства и методы сразу от
нескольких предков, однако на практике используется так называемое множественное
наследование. Для измерения глубины класса в таких случаях должна использоваться
метрика глубина класса в графе наследования
Метрика связана с сопровождаемостью и повторной используемостью программ. Вопервых, чем глубже конкретный класс в иерархии, тем более "проработанной" становится
проблемная область и выше потенциальное повторное использование унаследованных
методов (поскольку их становится все больше и больше). Но, во-вторых, чем глубже класс
в иерархии наследования и больше число методов в нем, тем сложнее предсказать
поведение объекта–представителя класса (а значит, и разобраться в том, что написано в
программе).
Пример:
Рассмотрим программу:
class GrandFather {};
class Father : public GrandFather {};
class Son : public Father {}
В этом случае:
 DIT(GrandFather) = 0
 DIT(Father) = 1
 DIT(Son) = 2.
3.7
Количество потомков (NOC)
Количество потомков (Number Of Children - NOC) позволяет определить количество
непосредственных потомков данного класса. Число дуг в простейшей модели иерархии
наследования классов, выходящих из вершины, соответствующей классу.
Шкала значений: абсолютная.
Вероятное влияние метрики на характеристики системы:
 Чем больше потомков у класса, тем больше повторное использование его методов.
Это положительное свойство.
 Чем больше потомков у класса, тем больше вероятность неправильного
использования базового класса-родителя. Это отрицательное свойство.
6

Чем больше потомков у класса, тем большее влияние он оказывает на систему в
целом. Такой класс требует более тщательного тестирования.
Пример:
Рассмотрим программу:
class
class
class
class
GrandFather {};
Father : public GrandFather {};
Mother : public GrandFather {};
Son : public Father, Mother{}
В этом случае:
 NOC(GrandFather) = 2
 NOC(Father) = 1
 NOC(Mother) = 1
 NOC(Son) =0.
3.8
Ширина иерархии наследования (BIH)
The breadth of the inheritance hierarchy (BIH). Максимальное число вершин на одном
уровне в простейшей модели наследования классов. Шкала значений: абсолютная. Эта
метрика применима только в том случае, когда иерархия наследования представлена
деревом.
3.9
Глубина класса в графе наследования (NL)
По существу, на практике используют две различные по смыслу метрики с этим
названием.
 сумма длин всех путей в простейшей модели наследования от корневых вершин до
рассматриваемой вершины;
 длина максимального пути в простейшей модели наследования от корневых
вершин до рассматриваемой вершины.
Nesting level (class-to-root-depth) is 1) the number of ancestors of a class) 2) the maximum
length from the node to a root of the tree. Кроме этих определений метрики существуют и
другие. Например, приводится пример вычисления глубины класса в графе наследования
как среднего арифметического значений глубины класса всех вершин – непосредственных
предков (parents) данной вершины. (Шкала значений интервальная.).
Данное определение справедливо только для ОО проектов и программ, в которых
использовано множественное наследование. Метрика связана с сопровождаемостью и
повторной используемостью программ аналогично DIT
3.10
Связанность между классами объектов (CBO)
Связанность между классами объектов (Coupling Between Object classes-CBO) позволяет
определить количество классов, с которыми связан данный класс. Это означает, что один
класс использует методы или экземпляры другого класса.
Вероятное влияние метрики на характеристики системы:
 Слишком большая связанность классов отрицательно влияет на модульность
проекта и не позволяет повторно использовать классы.
 Большое количество взаимосвязей увеличивает зависимость других частей
системы от данного класса и осложняет сопровождение системы в целом.
 Сильно взаимосвязанная система требует большего количества тестов и времени на
тестирование.
Метрика связана с повторным использованием программ и сопровождаемостью.
Чрезмерное сцепление классов препятствует повторному использованию. Чем больше
число пар связанных между собой классов объектов, тем выше чувствительность к
7
изменениям в других частях проекта и тем труднее сопровождение. Эта мера сцепления
полезна для определения того, насколько трудоемкой может оказаться проверка
различных частей проекта или программы. Чем выше сцепление между классами
объектов, тем более строгой должна быть проверка.
Заметим, что причины связанности классов в данной метрике значения не имеют.
Пример:
Рассмотрим программу:
class View {
};
class Node : public View {
Rect area;
};
class Edge : public View {
Node getNode1();
Node getNode2();
bool has(Point p);
};
В этом случае:
 CBO(View) = 2, поскольку он связан отношением наследования с двумя классамипотомками Node и Edge.
 CBO(Node) = 3, поскольку он связан отношением наследования с классом View и
отношением ассоциации с классом Rect. Кроме того, класс Node используется
классом Edge как результат вызова функций getNode1()и getNode2().
 CBO(Edge) = 3, поскольку он связан отношением наследования с классом View,
использует класс Node как результат вызова функций getNode1() и getNode2(), а
также использует класс Point как параметр функции has(Point p).
Количество реакций на класс (RFC)
3.11
Количество реакций на класс (Responce For Class - RFC) позволяет определить количество
методов, которое может быть выполнено в ответ на получение сообщения данным
классом. В этой метрике учитываются не только выполняемые методы данного класса, но
и методы других классов. Таким образом с помощью этой метрики можно оценить и
степень потенциального "общения" этого класса с другими классами.
Другими словами, если класс C имеет n методов Mi (т.е. {Mi}), а каждый метод Mi из
этого множества может обратиться к множеству {Rji} методов, расположенных как
внутри класса C, так и вне его (в каждом множестве Rji содержится ji элементов), то
объединение всех этих множеств называется множеством реакций (response set – RS)
класса C:
RS  M i  R ji
all _ i
Число элементов в множестве реакций класса называется реакцией класса C:
RFC  RS
На практике чаще принято вычислять значение метрики RFC для класса следующим
образом:
RFC 
 {R
ji
}
all _ i
Вероятное влияние метрики на характеристики системы:
 Большое количество методов, которые вызывается при вызове некоторого метода
класса, существенно осложняет тестирование и отладку этого класса. Это требует
большего понимания системы тем, кто ее тестирует.
8
Значения с наихудшим значением этой метрики требуют наибольшего времени
тестирования.
Метрика связана с сопровождаемостью программ, чем большее число методов может
быть вызвано в ответ на пришедшее сообщение, тем выше сложность класса и тем более
трудоемки тестирование и отладка класса.
Пример:
Рассмотрим программу:

class Edge : public View {
Node *node1, *node2;
void setArea(Point p1, Point p2);
void draw(Graphics *g){
Point c1 = node1->getCenter();
Point c2 = node2->getCenter();
g->drawLine(p1, p2);
setArea(p1, p2);
}
};
В этом случае:
RFC(Edge) = 3, поскольку он вызывает метод getCenter() класса Node, метод
drawLine(p1, p2) класса Graphics и собственный метод setArea(p1, p2).
Отсутствие сцепления в методах (LCOM)
3.12
Отсутствие сцепления в методах (Lack Cohesion Of Methods-LCOM) позволяет оценить
зависимость методов класса друг от друга. Эта метрика позволяет установить, не решают
ли методы одного класса "несколько задач". Для вычисления этой метрики
подсчитывается количество пар методов, которые не используют общие атрибуты класса.
Затем подсчитывается количество пар методов, которые используют общие переменные.
Метрика LCOM равна разности между первым числом и вторым. Если при этом
получается получается отрицательное число, то значение метрики считается раным 0.
Вероятное влияние метрики на характеристики системы:
 Отсутствие сцепления методов в классе желательно, поскольку увеличивает
инкапсуляцию атрибутов в классе.
 Отсутствие сцепления методов увеличивает вероятность его расщепления на два
подкласса.
 Большое сцепление методов класса увеличивает вероятность их ошибочного
поведения.
В литературе отмечается, что определение метрики как число компонентов связности
подграфа, соответствующего точкам внутри круга-вершины и связям между ними в
промежуточной модели взаимодействия обеспечивает метрику с порядковой шкалой.
Иногда предлагается метрика недостаток прочности класса, обеспечивающая шкалу
отношений. В соответствии с представленным ниже определением для каждого класса
рассматривается множество полей класса (n штук) и множество методов (Ai), связанных с
каждым i-ым полем класса. Метрика определяется следующим образом:
1 n
Ai )  m

n
i 1
НПК 
1 m
, где m – число методов класса.
(
Ai – множество точек-методов, связанных дугами с точкой-полем, n – число точек-полей,
m – число точек-методов. Метрика связана с сопровождаемостью программ, поскольку
низкая связность увеличивает сложность программ, а недостаток связности говорит о том,
что, возможно, класс должен быть разбит на два или более классов.
9
Пример:
Рассмотрим программу:
class Edge : public View {
Point *start, *end;
Node *node1, *node2;
Node getNode1() { return node1; }
Node getNode2() { return node2; }
void setArea(Point p1, Point p2){
start = p1;
end
= p2;
};
void draw(Graphics *g){
Point c1 = node1->getCenter();
Point c2 = node2->getCenter();
g->drawLine(p1, p2);
setArea(p1, p2);
}
};
Подсчитаем сцепление пар методов:
 N(getNode1, getNode2) = 0
 N(getNode1, setArea) = 0
 N(getNode1, draw) = 1, общий атрибут node1.
 N(getNode2, draw) = 1, общий атрибут node2.
 N(getNode2, setArea) = 0.
 N(setArea, draw) = 2, общие атрибуты node1 и node2 .
Пар, которые не используют общих атрибутов, 3. Использующих общие атрибуты 3. В
результате LCOM = 0.
3.13
Количество строк текста на класс (KLOC)
Количество строк текста на класс в килобайтах (Lines Of Class in K-KLOC) позволяет
оценить сложность реализации класса.
3.14
Число методов в классе (NM)
Число методов в классе (The number of methods - NM) - длина списка операций вершины в
промежуточной модели наследования, соответствующей классу т.е. число методов, как
определенных в классе, так и унаследованных от суперклассов. Кроме этого определения
метрики существует и другое, в соответствии с которым принимаются во внимание только
методы с различными именами. В терминах модели такое определение “звучит” как число
уникальных имен операций в списке операций вершины модели, соответствующей классу.
Шкала значений абсолютная.
Метрика связана с повторным использованием программ. Классы с большим числом
методов могут ограничивать возможность повторного использования. Кроме того, чем
больше число методов в классе, тем больше их потенциальное влияние на потомков,
наследующих все методы класса.
3.15
Число новых методов в классе (NNM)
Число новых методов в классе (The number of new methods - NNM) - длина списка
операций вершины в промежуточной модели наследования минус число входящих в
вершину дуг со значением атрибута тип, равным наследование метода. Шкала значений
абсолютная.
10
3.16
Количество унаследованных методов (NMI)
Количество методов, унаследованных от предков (Numer of Methods Inherited - NMI)
позволяет класса от его предков. В отличие от метрики DIT, эта метрика оценивает не
количество уровней в иерархии наследования, а именно зависимость от предков.
Возможно базовые классы не оказывают сильного влияния на потомков, если имеют
небольшое количество методов.
Метрика связана с повторным использованием программ, чем ниже доля унаследованных
методов в подклассе, тем больше вероятность того, что подкласс создан "неразумно".
Рекомендованные значения: число унаследо-ванных методов должно превосходить число
новых методов в классе, и тем больше превосходить, чем глубже класс расположен в
модели наследования
Пример:
Рассмотрим программу:
сlass View {
TRect getArea();
string getName();
};
сlass Node : public View {
Point* clipLine(Point p1, Point p2);
};
сlass ClassNode : public Node {
Point clipLine(Point p1, Point p2);
};
В этом случае:
 NMI(View) = 0
 NMI(Node) = 2,
 NMI(ClassNode) = 3.
3.17
Количество потенциально наследуемых методов (PMI)
Количество методов, унаследованных классом от предков (Potencial Methods Inherited PMI) + количество методов в самом классе. С помощью этой метрики вычисляется
степень функциональности, которую данный класс предоставляет своим потомкам.
Пример:
Рассмотрим программу:
сlass View {
TRect getArea();
string getName();
};
сlass Node : public View {
Point* clipLine(Point p1, Point p2);
};
сlass ClassNode : public Node {
Point clipLine(Point p1, Point p2);
};
PMI(View) = 2, PMI(Node) = 3, PMI(ClassNode) = 4.
3.18
Пропорция методов наследуемых подклассом (PMIS)
Пропорция методов, унаследованных классом от предков (Proportion of Methods Inherited
by a Subclass-PMIS). Эта метрика вычисляется по формуле:
11
PMIS = NMI /PMI
С помощью этой метрики вычисляется мера специализации класса по отношению к его
предкам.
Пример:
Рассмотрим программу:
сlass View {
TRect getArea();
string getName();
};
сlass Node : public View {
Point* clipLine(Point p1, Point p2);
};
сlass ClassNode : public Node {
Point clipLine(Point p1, Point p2);
};
В этом случае:
 NMI(View) = 0
 NMI(Node) = 2
 NMI(ClassNode) = 3
 PMI(View) = 2
 PMI(Node) = 3
 PMI(ClassNode) = 4
 PMIS(View) = 0
 PMIS(Node) = 0.666
 PMIS(ClassNode) = 0.75.
3.19
Число общедоступных методов в классе (NPM)
Число общедоступных методов в классе (The number of public methods in a class - NPM) число точек-методов с типом доступа “общедоступный” (public) в списке операций кругавершины полной модели наследования.
При вычислении данной метрики, рассматривают как определенные в классе, так и
унаследованные методы. В некоторых случаях рассматривают пару метрик: число
общедоступных методов, возвращающих значение некоторого типа, и число
общедоступных методов, не возвращающих никакого значения.
Метрика связана с сопровождаемостью ОО программ. Чем больше значение метрики, тем
выше затраты на сопровождение (maintenance effort in OO systems).
3.20
Степень методологической сцепленности (DMC)
Степень методологического сцепления (Density of Methodological Cohensiveness - DMC).
Эта метрика вычисляется как отношение количества пар методов, которые используют
общие атрибуты класса, к общему числу пар методов. В отличие от метрики LCOM, эта
метрика вычисляется более просто.
Пример:
Рассмотрим программу:
class Edge : public View {
Point *start, *end;
Node *node1, *node2;
Node getNode1() { return node1; }
Node getNode2() { return node2; }
12
void setArea(Point p1, Point p2){
start = p1;
end
= p2;
};
void draw(Graphics *g){
Point c1 = node1->getCenter();
Point c2 = node2->getCenter();
g->drawLine(p1, p2);
setArea(p1, p2);
}
};
Подсчитаем сцепление пар методов:
 N(getNode1, getNode2) = 0
 N(getNode1, setArea) = 0
 N(getNode1, draw) = 1, общий атрибут node1.
 N(getNode2, draw) = 1, общий атрибут node2.
 N(getNode2, setArea) = 0.
 N(setArea, draw) = 2, общие атрибуты node1 и node2 .
Использующих общие атрибуты 3. Всего пар 6. В результате DMC = 0.5
3.21
Количество посылаемых методом сообщений (NMS)
Количество сообщений, посылаемых данным методом (Number of Message-Sends-NMS)
позволяет оценить степень коммуникационной сложности метода.
Пример:
Рассмотрим программу:
class Edge : public View {
Node *node1, *node2;
void setArea(Point p1, Point p2);
void draw(Graphics *g){
Point c1 = node1->getCenter();
Point c2 = node2->getCenter();
g->drawLine(p1, p2);
setArea(p1, p2);
}
};
В этом случае:
NMS(Edge) = 2, поскольку он вызывает метод getCenter() класса Node, метод
drawLine(p1, p2) класса Graphics.
3.22
Сообщения и аргументы (MAA)
Сообщения и аргументы (Messages And Arguments - MAA) позволяет степень
коммуникационной сложности метода учитывая количество предаваемых в сообщение
параметров. При подсчете количества посылаемых методом сообщений к количеству
сообщений добавляется и количество передаваемых в сообщении параметров.
Поскольку количество передаваемых в сообщениях параметров увеличивает
коммуникационную сложность метода, в некоторых случаях эта метрика более точна, чем
метрика NMS. Вместе с тем, в других случаях требуется именно количество посылаемых
методом сообщений, поскольку сообщения и их параметры не равнозначны.
13
Пример:
Рассмотрим программу:
class Edge : public View {
Node *node1, *node2;
void setArea(Point p1, Point p2);
void draw(Graphics *g){
Point c1 = node1->getCenter();
Point c2 = node2->getCenter();
g->drawLine(p1, p2);
setArea(p1, p2);
}
};
В этом случае:
MAA(Edge) = 4, поскольку он вызывает метод getCenter() класса Node без
параметров и метод drawLine(p1, p2) класса Graphics с двумя параметрами.
Данная метрика может быть использована для оценки необходимости повторного
проектирования классов. Необходимо оценить, насколько оправдана коммуникационная
сложность метода. Возможно, что необходимо переместить метод с высоким значением
метрики в класс, из которого этот метод чаще всего вызывается. В этом случае, возможно,
у него будет меньше параметров.
Пример:
Рассмотрим программу:
class Triangle {
Point p1, p2, p3;
Graphics *g;
void draw() {
g->drawTriangle(p1, p2, p3);
}
};
class Graphics {
Color color;
Color getColor();
void drawTriangle(Point p1, Point p2, Point p3) {
}
};
В классе Triangle метод draw вызывает метод drawTriangle класса Graphics с тремя
параметрами. Это увеличивает его коммуникационную сложность. Если перенести метод
drawTriangle в класс Triangle, то можно будет уменьшить число параметров в этом
методе.
Ниже показана программа после повторного проектирования классов. Метод
drawTriangle(Point p1, Point p2, Point p3)заменен на метод draw(Color color):
class Triangle {
Point p1, p2, p3;
Graphics *g;
void draw() {
draw(g->getColor());
}
void draw(Color color) {
}
};
14
class Graphics {
Color color;
Color getColor();
};
3.23
Количество абстрактных классов (NAC)
Количество абстрактных классов (Number of Abstract Classes-NAC), число вершин в
простейшей модели иерархии наследования, значение атрибута тип которых равно
абстрактный. Абстрактные классы - это классы, для которых не предполагается создавать
экземпляры. В языке С++ это классы, которые имеют чистые виртуальные методы.
Методы абстрактных классов реализуются в потомках абстрактного класса. Абстрактные
классы создаются для увеличения повторного использования их методов в классахпотомках. Метрика NAC позволяет оценить, каким образом степень повторного
использования методов с помощью абстрактных классов. Метрика связана с повторным
использованием программ, поскольку создание абстрактных классов способствует
повторному использованию методов и уменьшением, тем самым, затрат на выявление
общих понятий в прикладной области.
В литературе приводится статистика из практики – рекомендуется иметь 10-15%
абстрактных классов среди общего числа классов.
3.24
Степень абстрактности классов (DAC)
Степень абстрактности классов (Density of Abstract Classes-DAC). Эта метрика содержит
отношение абстрактных классов к общему числу классов. Как дополнение к метрике NAC,
эта метрика позволяет сравнивать абстрактность программ разного размера.
В литературе упоминается также метрика число аггрегатных связей ("the number of
aggregation relationships"), которая отражает, по сути, один из вариантов определенной
выше метрики, а именно, число классов, представители которых являются полями данного
класса. В терминах полной модели взаимодействия компонентов метрика может быть
выражена как число кругов-вершин, связанных с данной вершиной дугами с видимостью,
равной “компонент класса”.
3.25
Количество переопределеных методов в подклассе (NMO)
Количество переопределенных методов в подклассе (Number of Methods OverwrittenNMO) - Число дуг со значениями переопределение метода и переопределение свойства
атрибута тип, выходящих из вершины промежуточной модели наследования классов. Эта
метрика определяет количество методов класса-предка, переопределенных в классепотомке. Правильное проектирование системы предполагает расширение классовпредков, а не их переопределение. Большая величина этой метрики сигнализирует об
ошибках проектирования.
На практике рассматривают такую метрику не только для классов, но и для
компонентов классов – методов и свойств. В терминах модели метрика число
переопределений для метода определяется как число дуг с типом “переопределение
метода”, выходящих из точки-метода в промежуточной модели наследования классов.
Метрика связана с сопровождаемостью программ, поскольку чрезмерная глубина
иерархии наследования классов в сочетании с переопределением методов в подклассах
увеличивает сложность ОО программ.
Рекомендуемые значения - большие значения метрики оправданы лишь для так
называемых frameworks (framework – collection of classes that provide a set of services for a
particular domain; a framework thus exports a number of individual classes and mechanisms that
clients can use or adapt [4]).
15
Пример:
Рассмотрим программу:
class View {
Rect area;
virtual Rect getArea()
{ return area; }
};
class SegmentedEdge : public View {
vector<Point> segments;
virtual Rect getArea() {
Rect r(segments[0]);
for (int i = 1; i < segments.size(); i++)
r |= Rect(segments[i]);
return r;
}
};
Метрика NMO(SegmentedEdge) = 1, поскольку класс SegmentedEdge
переопределяет метод класса getArea() класса View.
Класс View является базовым классом для классов, которые представляют на экране
некоторые фигуры. Для этого класса ошибочно был реализован метод, который "выдает"
прямоугольную область, к которую попадает фигура. Для этого в классе View имеется
переменная area. Однако этот метод getArea переопределяется в классе
SegmentedEdge, который представляет на экране ломаную линию. При этом
переменная View::area и метод View::getArea()становятся излишними.
Правильным решением было бы сделать View::getArea()чистой виртуальной, а
базовый класс View абстрактным.
Метрика NMO(SegmentedEdge) в этом случае становится равной 0.
3.26
Пропорция переопределения методов в подклассе (POM)
Пропорция переопределения методов в подклассе (Proportion of Overridden Methods in
Class-POM). Эта метрика вычисляется как отношение:
POM = число переопределенных методов подкласса / общее число методов подкласса
Эта метрика, как дополнение к метрике NMO, позволяется сравнивать абстрактность
программ разного размера. Например, одну и ту же программу, но на разных этапах ее
разработки
3.27
Число свойств (атрибутов или переменных) в классе(NAA)
Число свойств (атрибутов или переменных) в классе (The total number of available attributes
(NAA)) - длина списка свойств вершины в промежуточной модели наследования.
Считается, что нулевое значение метрики показывает, что программа не является хорошо
продуманной ОО программой
Число унаследованных свойств (атрибутов или
переменных) в классе (NIV)
3.28
Число унаследованных свойств (The number of inherited variables - NIV) - Число дуг в
промежуточной модели наследования со значением наследование свойства атрибута тип,
входящих в вершину.
3.29
Использование глобалов (GUS)
Использование глобальных переменных (Global Usage - GUS). При вычислении этой
метрики подсчитывается количество глобальных переменных, в том числе глобальных
переменных для всей системы, а также количество переменных класса, глобальных для
этого класса.
16
Ситуация с использованием глобальных переменных в программах на языке C++ часто
возникает, если эти программы используют старые программы написанные на языке С.
Метрика GUS позволяет выявить такие зависимости.
3.30
Излишняя взаимосвязь через глобалы (UCGU)
Излишняя взаимосвязь через глобальные переменные (Unnesessary Coupling through Global
Usage - UCGU). При вычислении этой метрики подсчитывается сколько раз глобальные
переменные, определенные метрикой GUS, были использованы.
Метрика UCGU позволяет оценить степень влияния глобальных переменных на систему в
целом. Возможно зависимость от глобальных переменных локализована в каком либо
одном классе, и такое влияние не велико. Однако возможна и обратная ситуация, когда
глобальные переменные используются часто и в большом количестве классов.
3.31
Степень взаимосвязи между классами (DCBO)
Степень взаимосвязи между классами (Degree of Coupling between Classes - DCBO). Эта
метрика используется как дополнение к метрике DCO. Метрика DCO подсчитывает
количество классов, с которыми данный класс разделяет атрибуты и методы. Метрика
DCBO подсчитывает только методы данного класса, используемые из других классов.
Если методы данного класса никому не нужны, то DCBO=0.
3.32
Количество скрытых методов экземпляра (PrIM)
Количество скрытых (private) методов экземпляра (Number of Private Instance Methods PrIM) позволяет степень скрытия информации классом.
3.33
Мера Мак-Клура (MMK)
Мера Мак-Клура предназначена для управления сложностью структурированных
программ в процессе проектирования. Она применяется к иерархическим схемам
разбиения программ на модули, что позволяет выбрать схему разбиения с меньшей
сложностью задолго до написания программы. Метрикой выступает зависимость
сложности программы от числа возможных путей исполнения, числа управляющих
конструкций и числа переменных (от которых зависит выбор пути). Методика расчета
сложности по Мак-Клуру четко ориентирована на хорошо структурированные программы.
Тестирующей мерой М называется мера сложности, удовлетворяющая следующим
условиям:
1.Мера сложности простого оператора равна 1;
2.М ({F1; F2; ┘;Fn}) = еin M(Fi);
3.М (IF P THEN F1 ELSE F2) = 2 MAX (M (F1), M (F2));
4. М (WHILE P DO F) = 2 M(F).
Мера возрастает с глубиной вложенности и учитывает протяженность программы. К
тестирующей мере близко примыкает мера на основе регулярных вложений. Идея этой
меры сложности программ состоит в подсчете суммарного числа символов (операндов,
операторов, скобок) в регулярном выражении с минимально необходимым числом скобок,
описывающим управляющий граф программы. Все меры этой группы чувствительны к
вложенности управляющих конструкций и к протяженности программы. Однако
возрастает уровень трудоемкости вычислений.
4. Литература
С.А Орлов “Технологии разработки программного обеспечения”, Питер, 2002
TogetherJ official web site. http://www.togethersoft.com
C and C++ Code Counter. http://www.fste.ac.cowan.edu.au
Booch G. Object-oriented analysis and design with application. Second edition. The
Benjamin/Cummings Publishing Company, Inc. 1994.
5. Кнут Д. Искусство программирования на ЭВМ, т. 1 «Основные алгоритмы». М.,
Мир, 1976 т. 3 « Сортировка и поиск». М., Мир, 1978.
6. М. Холстед. Начала науки о программах. Москва, 1981
1.
2.
3.
4.
17