MARYNA DIDKOVSKA МЕТРИКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

МЕТРИКИ 1.ВВЕДЕНИЕ 2.ИЗМЕРЕНИЯ 3.ТИПЫ

SOFTWARE METRICS. OBJECTIVE To describe the current state-of-the-art in the measurement of software products and process.

WHY MEASURE? "When you can measure what you are speaking about and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind: it may be the beginnings of knowledge but you have scarcely in your thoughts advanced to the stage of Science. Lord Kelvin (Physicist) "You cannot control what you cannot measure. Tom DeMarco (Software Engineer)

MEASUREMENT. DEFINITION Measurement is the assignment of numbers to objects or events according to rule. [S. S. Stevens,1946] Measurement is the process of empirical, objective, assignment of numbers to properties of objects or events of the real world in such a way as to describe them. [L.Finkelstein, 1982] Measurement is the process by which numbers or symbols are assigned to attributes of entities in the real world in such a way as to characterize them according to clearly defined rules. [N. E. Fenton and S. L. Pfleeger, 1997] Measurement is "the act or process of assigning a number or category to an entity to describe an attribute of that entity [IEEE Std ]. Fundamental measurement is a means by which numbers can be assigned according to natural laws to represent the property, and yet which does not presuppose measurement of any other variables [W. Torgerso, 1958]

TEN QUESTIONS ABOUT MEASUREMENTS 1.What is the purpose of this measure? 2.What is the scope of this measure? 3.What attribute are we trying to measure? 4.What is the natural scale of the attribute we are trying to measure? 5.What is the natural variability of the attribute? 6.What is the metric (the function that assigns a value to the attribute)? 7.What is the natural scale for this metric? 8.What is the natural variability of readings from this instrument? 9.What is the relationship of the attribute to the metric value? 10.What are the natural and foreseeable side effects of using this instrument?

TYPES OF METRIC direct measurement eg number of lines of code indirect/ derived measurement eg defect density = no. of defects in a software product / total size of product prediction eg predict effort required to develop software from measure of the functionality - function point count

TYPES OF METRIC nominal eg no ordering, simply attachment of labels (language: 3GL, 4GL) ordinal eg ordering, but no quantitative comparison (programmer capability: low, average, high)

TYPES OF METRIC interval eg between certain values (programmer capability: between 55th and 75 th percentile of the population ability) ratio eg (the proposed software is twice as big as the software that has just been completed) absolute eg the software is 350,000 lines of code long

TYPES OF METRIC product metrics size metrics complexity metrics quality metrics process metrics resource metrics project metrics

МЕТРИКИ РАЗМЕРА ПРОГРАММЫ 1. МЕТРИКИ РАЗМЕРА ПРОГРАММ В СТРОКАХ КОДА (LOC-ОЦЕНКИ) 2. МЕТРИКИ ХОЛСТЕДА

1. МЕТРИКИ РАЗМЕРА ПРОГРАММ В СТРОКАХ КОДА (LOC-ОЦЕНКИ) Source Lines Of Code, SLOC количество «физических» SLOC ( LOC, SLOC, KLOC, KSLOC, DSLOC) – общее число строк исходного кода, включая комментарии и пустые строки); количество «логических» SLOC (LSI, DSI, KDSI, где SI – Source Instructions) – определяется как число команд и зависит от используемого языка программирования.

2. МЕТРИКИ ХОЛСТЕДА - ДАННЫЕ: число уникальных операторов программы ( Number of Unique Operators, NUOprtr ), включая символы-разделители, имена процедур и знаки операций – словарь операторов; число уникальных операндов программы ( Number of Unique Operands, NUOprnd ) – словарь операндов; полное число операторов в программе ( Number of Operators, Noprtr ); полное число операндов в программе ( Number of Operands, Noprnd ).

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

ФУНКЦИОНАЛЬНО- ОРИЕНТИРОВАННЫЕ МЕТРИКИ 1.МЕТРИКА ФУНКЦИОНАЛЬНЫХ ТОЧЕК

ФУНКЦИОНАЛЬНО- ОРИЕНТИРОВАННЫЕ МЕТРИКИ Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. рассматривается не размер, а функциональность или полезность продукта Количество внешних вводов Количество внешних выводов Количество внешних запросов Количество внутренних логических файлов Количество внешних интерфейсных файлов

ПРИМЕРЫ ЭЛЕМЕНТОВ ДАННЫХ

ЭЛЕМЕНТЫ ДАННЫХ Внутренний логический файл распознаваемая пользователем группа логически связанных данных, которая размещена внутри приложения и обслуживается через внешние вводы. Внешний интерфейсный файл распознаваемая пользователем группа логически связанных данных, которая размещена внутри другого приложения и поддерживается им. Внешний файл данного приложения является внутренним логическим файлом в другом приложении.

КОЛИЧЕСТВО ФУНКЦИОНАЛЬНЫХ ТОЧЕК После сбора всей необходимой информации приступают к расчету метрики количества функциональных точек FP (Function Points ). Автором этой метрики является А. Албрехт (1979)

ИСХОДНЫЕ ДАННЫЕ ДЛЯ РАСЧЕТА FP-МЕТРИК где F i коэффициенты регулировки сложности. Каждый коэффициент может принимать следующие значения: 0 нет влияния, 1 случайное, 2 небольшое, 3 среднее, 4 важное, 5 основное

ОПРЕДЕЛЕНИЕ СИСТЕМНЫХ ПАРАМЕТРОВ ПРИЛОЖЕНИЯ

1. МЕТРИКИ НА БАЗЕ FP После вычисления FP на его основе формируются метрики производительности, качества и т. д.:

ПЕРЕСЧЕТ FP-ОЦЕНОК В LOC-ОЦЕНКИ

МЕТРИКИ СЛОЖНОСТИ ПОТОКА УПРАВЛЕНИЯ ПРОГРАММ 1.1. МЕТРИКИ ЦИКЛОМАТИЧЕСКОЙ СЛОЖНОСТИ МАККЕЙБА 2. МЕТРИКА МАЙЕРСА 3. МЕТРИКА ДЖИЛБА 4. МЕТРИКА 'ПОДСЧЕТ ТОЧЕК ПЕРЕСЕЧЕНИЯ' 5. МЕТОД ГРАНИЧНЫХ ЗНАЧЕНИЙ

1. МЕТРИКИ ЦИКЛОМАТИЧЕСКОЙ СЛОЖНОСТИ МАККЕЙБА V(G)=e n + 2p, где e количество дуг, n количество вершин, p число компонент связности. в корректно написанных программах p=1, V(G)=e n + 2. IF X = Z THEN Statement 2; END

1. МЕТРИКИ ЦИКЛОМАТИЧЕСКОЙ СЛОЖНОСТИ МАККЕЙБА IF A = 354 THEN IF B > C THEN A = B ELSE A = C ENDIF ENDIF Print A cyclomatic complexity Is = 3

2. МЕТРИКА МАЙЕРСА В качестве оценки предложено взять интервал [V(G),V(G)+h], где V(G) – метрика МакКейба, h для простых предикатов равно нулю, а для n-местных h=n-1

3. МЕТРИКА ДЖИЛБА насыщенность программы выражениями IF_THEN_ELSE СL - абсолютная сложность программы, характеризующаяся количеством операторов условия; cl - относительная сложность программы, характеризующаяся насыщенностью программы операторами условия. cl=CL/N N -общее число операторов

4. МЕТРИКА 'ПОДСЧЕТ ТОЧЕК ПЕРЕСЕЧЕНИЯ' В графе программы, где каждому оператору соответствует вершина, т.е. не исключены линейные участки, при передаче управления от вершины 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).

5. МЕТОД ГРАНИЧНЫХ ЗНАЧЕНИЙ 1 G=(V,E) - ориентированный граф программы с единственной начальной и единственной конечной вершинами. Число входящих в вершину дуг называется отрицательной степенью вершины, Число исходящих из вершины дуг - положительной степенью вершины. набор вершин графа можно разбить на две группы: Принимающие вершины, у которых положительная степень =2.

5. МЕТОД ГРАНИЧНЫХ ЗНАЧЕНИЙ 2 Принимающие вершины и вершины отбора

5. МЕТОД ГРАНИЧНЫХ ЗНАЧЕНИЙ 3 Характеристики подграфов программ Вершины отбора abcd Вершины переходаb,cb,cb,de,fg,hg,h Скорректированная сложность вершины графа Вершины подграфаb,c,d, e,f,g, h,i,j b l,j g,h g,h Нижняя граница подграфаkdij S 0 =1-(v-1)/S a где S 0 – относительная граничная сложность программы; S a – абсолютная граничная сложность программы, v – общее число вершин графа программы. S 0 =1-(11/25)=0,56.

МЕТРИКИ СЛОЖНОСТИ ПОТОКА ДАННЫХ 1.МЕТРИКА 'МОДУЛЬ – ГЛОБАЛЬНАЯ ПЕРЕМЕННАЯ' 2.МЕТРИКА ЧЕПИНА 3.МЕТРИКА СПЕНА 4.МЕТРИКА ОВИЕДО

1.МЕТРИКА 'МОДУЛЬ – ГЛОБАЛЬНАЯ ПЕРЕМЕННАЯ' Пара модуль – глобальная переменная обозначается как (p,r), где p – модуль, имеющий доступ к глобальной переменной r. Формируются два типа пар модуль – глобальная переменная : фактические и возможные. Aup -сколько раз модули действительно получили доступ к глобальным переменным; Pup – сколько раз они могли бы получить доступ. Отношение числа фактических обращений к возможным : Rup=Aup/Pup

1.МЕТРИКА 'МОДУЛЬ – ГЛОБАЛЬНАЯ ПЕРЕМЕННАЯ - 2 Пусть в программе имеются три глобальные переменные и три подпрограммы. Предположим, что каждая подпрограмма имеет доступ к каждой из переменных, тогда возможных пар - 9, то есть Pup=9. Пусть первая подпрограмма обращается к одной переменной, вторая – двум, а третья не обращается ни к одной переменной. Aup=3, Rup=3/9.

2. МЕТРИКА ЧЕПИНА -1 Оценка информационной прочности отдельно взятого программного модуля с помощью анализа характера использования переменных из списка ввода-вывода. Множество «Р» – вводимые переменные для расчетов и для обеспечения вывода. Множество «М» – модифицируемые или создаваемые внутри программы переменные. Множество «C» – переменные, участвующие в управлении работой программного модуля. Множество «Т» – не используемые в программе (паразитные) переменные.

2. МЕТРИКА ЧЕПИНА -2 Q = a 1 P + a 2 M + a 3 C + a 4 T,где a 1, a 2, a 3, a 4 – весовые коэффициенты. наибольший вес, равный трем, имеет функциональная группа С, так как она влияет на поток управления программы. a 3 =3 a 1 =1; a 2 =2; a 4 =0.5. Q = P + 2M + 3C + 0.5T.

3. МЕТРИКА СПЕНА Спен – число утверждений, содержащих данный идентификатор, между его первым и последним появлением в тексте программы. Идентификатор, появившийся n раз, имеет спен, равный n-1. При большом спене усложняется тестирование и отладка.

4. МЕТРИКА ОВИЕДО программа разбивается на линейные непересекающиеся участки лучи операторов, которые образуют управляющий граф программы. R(i) множество определяющих вхождений переменных, которые расположены в радиусе действия луча i V(i) множество переменных, использующие вхождения которых уже есть в луче i мера сложности i-го луча: DF(i)=СУММА(DEF(v j )), j=1...||V(i)|| где DEF(v j ) число определяющих вхождений переменной v j из множества R(i), а ||V(i)|| мощность множества V(i).

МЕТРИКИ СТИЛИСТИКИ И ПОНЯТНОСТИ ПРОГРАММ 1.МЕТРИКА УРОВНЯ КОММЕНТИРОВАННОСТИ ПРОГРАММНОГО КОДА 2.МЕТРИКИ ХОЛСТЕДА

1. МЕТРИКА УРОВНЯ КОММЕНТИРОВАННОСТИ ПРОГРАММНОГО КОДА F = N ком /N стр, где N ком - количество комментариев в программе; N стр – количество строк или операторов исходного текста. метрика F отражает насыщенность программы комментариями. программа разбивается на n равных сегментов и для каждого из них определяется F i : F i =sign(N ком /N стр –0.1), при этом Уровень комментированности программы считается нормальным, если выполняется условие: F=n.

2. МЕТРИКИ ХОЛСТЕДА Теоретическая длина программы где n 1 - словарь операторов; n 2 - словарь операндов программы идеализированная аппроксимация N=N 1 +N 2, т.е. справедливо для потенциально корректных программ, свободных от стилистических ошибок, но если: а) последующая операция уничтожает результаты предыдущих без их использования; б) присутствуют тождественные выражения, решающие совершенно одинаковые задачи; в) одной и той же переменной назначаются различные имена и т.п. N изменяется без изменения h. Длина корректно составленной программы N имеющей словарь h, не должна отклоняться от теоретической длины программы более чем на 10% - иначе вывод о наличии стилистических ошибок

ОСОБЕННОСТИ СТРУКТУРИРОВАНИЯ СИСТЕМЫ 1.СВЯЗНОСТЬ МОДУЛЯ 2. СЦЕПЛИВАНИЕ МОДУЛЕЙ

СВЯЗНОСТЬ МОДУЛЯ - COHESION Связность модуля (Cohesion) это мера зависимости его частей Это внутренняя характеристика модуля. Чем выше связность модуля, тем лучше результат проектирования

COHESION TYPES Связность по совпадению (СС=0). В модуле отсутствуют явно выраженные внутренние связи. 2. Логическая связность (СС=1). Части модуля объединены по принципу функционального подобия. Например, модуль состоит из разных подпрограмм обработки ошибок. При использовании такого модуля клиент выбирает только одну из подпрограмм. Недостатки: сложное сопряжение; большая вероятность внесения ошибок при изменении сопряжения ради одной из функций. 3. Временная связность (СС=3). Части модуля не связаны, но необходимы в один и тот же период работы системы. Недостаток: сильная взаимная связь с другими модулями, отсюда сильная чувствительность внесению изменений.

COHESION TYPES Процедурная связность (СС=5). Части модуля связаны порядком выполняемых ими действий, реализующих некоторый сценарий поведения. 5. Коммуникативная связность (СС=7). Части модуля связаны по данным (работают с одной и той же структурой данных). 6. Информационная (последовательная) связность (СС=9). Выходные данные одной части используются как входные данные в другой части модуля. 7. Функциональная связность (СС=10). Части модуля вместе реализуют одну функцию

ХАРАКТЕРИСТИКА СВЯЗНОСТИ МОДУЛЯ

ОПРЕДЕЛЕНИЕ СВЯЗНОСТИ МОДУЛЯ 1.Если модуль единичная проблемно-ориентированная функция, то уровень связности функциональный; конец алгоритма. В противном случае перейти к пункту Если действия внутри модуля связаны, то перейти к пункту 3. Если действия внутри модуля никак не связаны, то перейти к пункту Если действия внутри модуля связаны данными, то перейти к пункту 4. Если действия внутри модуля связаны потоком управления, перейти к пункту 5. 4.Если порядок действий внутри модуля важен, то уровень связности информационный. В противном случае уровень связности коммуникативный. Конец алгоритма. 5.Если порядок действий внутри модуля важен, то уровень связности процедурный. В противном случае уровень связности временной. Конец алгоритма. 6.Если действия внутри модуля принадлежат к одной категории, то уровень связности логический. Если действия внутри модуля не принадлежат к одной категории, то уровень связности по совпадению. Конец алгоритма.

НЕСКОЛЬКО УРОВНЕЙ СВЯЗНОСТИ правило параллельной цепи. Если все действия модуля имеют несколько уровней связности, то модулю присваивают самый сильный уровень связности; правило последовательной цепи. Если действия в модуле имеют разные уровни связности, то модулю присваивают самый слабый уровень связности.

СЦЕПЛИВАНИЕ МОДУЛЕЙ - COUPLING 1. Сцепление по данным (СЦ=1). Модуль А вызывает модуль В. Все входные и выходные параметры вызываемого модуля простые элементы данных 2. Сцепление по образцу (СЦ=3). В качестве параметров используются структуры данных

СЦЕПЛИВАНИЕ МОДУЛЕЙ - COUPLING 3. Сцепление по управлению (СЦ=4). Модуль А явно управляет функционированием модуля В (с помощью флагов или переключателей), посылая ему управляющие данные

СЦЕПЛИВАНИЕ МОДУЛЕЙ - COUPLING 4. Сцепление по внешним ссылкам (СЦ=5). Модули А и В ссылаются на один и тот же глобальный элемент данных. 5. Сцепление по общей области (СЦ=7). Модули разделяют одну и ту же глобальную структуру данных. 6. Сцепление по содержанию (СЦ=9). Один модуль прямо ссылается на содержание другого модуля (не через его точку входа). Например, коды их команд перемежаются друг с другом модули В и D сцеплены по содержанию, а модули С, Е и N сцеплены по общей области.

ОБЪЕКТНО-ОРИЕНТИРОВАННЫЕ МЕТРИКИ 1.1.СВЯЗНОСТЬ COHESION (ПО ДАННЫМ ПО МЕТОДАМ) 2.2.СЦЕПЛИВАНИЕ МЕЖДУ КЛАССАМИ - COUPLING 3.3.ЛОКАЛЬНОСТЬ ДАННЫХ - LD 4.4.МЕТРИКИ ЧИДАМБЕРА И КЕМЕРЕРА 5.5.МЕТРИКИ ЛОРЕНЦА И КИДДА 6.6.МЕТРИКИ ФЕРНАНДО АБРЕУ 7.7.МЕТРИКИ БАЙНДЕРА

СВЯЗНОСТЬ ОБЪЕКТОВ Связность по совпадению. Логическая связность Временная связность. Процедурная связность. Коммуникативная связность. Информационная (последовательная) связность. Функциональная связность. Объектная связность. Каждая операция обеспечивает функциональность, которая предусматривает, что все свойства объекта будут модифицироваться, отображаться и использоваться как базис для предоставления услуг.

МЕТРИКИ СВЯЗНОСТИ ПО ДАННЫМ Л. Отт и Б. Мехра - модель секционирования класса Измерение связности основывается на количестве лексем данных (data tokens), которые появляются в нескольких секциях и «склеивают» секции в модуль. Под лексемами данных понимают определения констант и переменных или ссылки на константы и переменные. Секция данных это последовательность лексем данных в операторах, которые требуются для вычисления этого параметра. Секционированная абстракция класса (Class Slice Abstraction) CSA(C ) - объединение секций всех экземплярных переменных класса Сильно склеенные лексемамы - склеенные лексемы, которые являются элементами всех секций данных

МЕТРИКИ СВЯЗНОСТИ ПО ДАННЫМ Сильная связность по данным (StrongData Cohesion) где SG(CSA(C)) объединение сильно склеенных лексем каждого из методов класса С, лексемы(С) множество всех лексем данных класса С. Слабая связность по данным (Weak Data Cohesion) где G(CSA(C)) объединение склеенных лексем каждого из методов класса. Клейкость данных (Data Adhesiveness). CSA(C) - Class Slice Abstraction

ПРИМЕР включает две секции с 16 лексемами, имеет 6 сильно склеенных лексем ( 6 склеенных лексем). SDC = 6/16 = 0,375= WDC DA =(6*2)/(16*2) = 0,375 SumNProdNОператор procedure SumAndProduct 11(N:integer; 11var SumN, ProdN:integer) var 11k:integer; begin 2 SumN:=0 2ProdN:=1 33for k:=1 to N do begin 3 SumN:=SumN+l 3ProdN:=ProdN*k end end;

МЕТРИКИ СВЯЗНОСТИ ПО МЕТОДАМ Если существуют общие экземплярные переменные (одна или несколько), используемые в паре методов, то говорят, что эти методы соединены прямо. Пара методов может быть соединена косвенно, через другие прямо соединенные методы. Прямоугольниками обозначены методы класса, а овалами экземплярные переменные.

МЕТРИКИ СВЯЗНОСТИ ПО МЕТОДАМ Для формализации модели вводятся понятия Абстрактный метод АМ(М) - это представление реального метода М в виде множества экземплярных переменных, которые прямо DU(M) или косвенно IU(M используются методом. Количественно: AM (М) = DU (М) IU (М) Абстрактный класс АС(С) это представление реального класса С в виде совокупности абстрактных методов, причем каждый абстрактный метод соответствует видимому методу класса С. Количественно в форме мультимножества: АС (С) = [[AM (M) | M V (С) ]], где V(C) множество всех видимых методов в классе С и в классах предках для С.

МЕТРИКИ СВЯЗНОСТИ ПО МЕТОДАМ Локальный абстрактный класс LAC(C) это совокупность абстрактных методов, где каждый абстрактный метод соответствует видимому методу, определенному только внутри класса С. Количественно : LAC (C) =[[AM (M)|M LV (C) ]], где LV(C) множество всех видимых методов, определенных в классе С. NP (C) общее количество пар абстрактных методов в AC(C)- максимально возможное количество прямых или косвенных соединений в классе. Если в классе С имеются N методов, тогда NP (C) = N*(N-1 )/2

МЕТРИКИ СВЯЗНОСТИ ПО МЕТОДАМ NDC (C) количество прямых соединений AC(C); NIC (C) количество косвенных соединений в АС(С). метрики связности класса : сильная связность класса (Tight Class Cohesion (ТСС)) относительное количество прямо соединенных методов: ТСС (С) = NDC (С) / NP (С); слабая связность класса (Loose Class Cohesion (LCC)) относительное количество прямо или косвенно соединенных методов: LCC (С) = (NDC (С) + NIC (С) ) / NP (С). всегда справедливо следующее неравенство: LCC (C) >=TCC (C).

МЕТРИКИ СВЯЗНОСТИ ПО МЕТОДАМ

ЗАВИСИМОСТЬ ИЗМЕНЕНИЯ МЕЖДУ КЛАССАМИ – CLASS LEVEL COUPLING CDBC (Change Dependency Between Classes) - потенциальный объем изменений, необходимых после модификации класса-сервера SC (server class) на этапе сопровождения. пока реальное количество необходимых изменений класса-клиента СС (client class) неизвестно, CDBC указывает количество методов, на которые влияет изменение SC. CDBC зависит от: области видимости изменяемого класса-сервера внутри класса-клиента (определяется типом отношения между CS и СС); вида доступа СС к CS (интерфейсный доступ или доступ реализации).

ВКЛАД ОТНОШЕНИЙ МЕЖДУ CC И CS В ЗАВИСИМОСТЬ ИЗМЕНЕНИЯ CDBC(CC, SC) = min(n, A). Пути минимизации CDBC: 1) ограничение доступа к интерфейсу класса-сервера; 2) ограничение видимости классов-серверов (спецификаторами доступа public, protected, private).

ЛОКАЛЬНОСТЬ ДАННЫХ Метрика, отражающая качество абстракции, реализуемой классом. Чем выше локальность данных, тем выше самодостаточность класса. L i (1.. n) множество локальных переменных, к которым имеют доступ методы M i (прямо или с помощью методов чтения/записи). T i (1..n) множество всех переменных, используемых в M i, кроме динамических локальных переменных, определенных в M i

МЕТРИКИ ЧИДАМБЕРА И КЕМЕРЕРА-1 Метрика 1: Взвешенные методы на класс WMC (Weighted Methods Per Class) – относительная мера сложности класса в классе С определены п методов со сложностью с 1..., c i,..., с n Упрощенная версия метрики c i =1, WMC –кол-во методов в классе Варианты: унаследованные методы учитываются, не учитываются, учитываются от прямых родителей

МЕТРИКИ ЧИДАМБЕРА И КЕМЕРЕРА-2 Метрика 2: Высота дерева наследования DIT (Depth of Inheritance Tree) DIT определяется как максимальная длина пути от листа до корня дерева наследования классов +большая DIT - многие методы могут использоваться многократно. - большая сложность проекта

МЕТРИКИ ЧИДАМБЕРА И КЕМЕРЕРА- 3,4 Метрика 3: Количество детей NOC (Number of children) NOC равно количеству детей, то есть количеству непосредственных наследников класса в иерархии классов. следует строить сбалансированные по высоте и ширине структуры наследования: обычно не выше, чем 7 ± 2 уровня, и не шире, чем ветви [Г.Буч] Метрика 4: Сцепление между классами объектов СВО (Coupling between object classes) СВО количество сотрудничеств, предусмотренных для класса, то есть количество классов, с которыми он соединен. Соединение означает, что методы данного класса используют методы или экземплярные переменные другого класса.

МЕТРИКИ ЧИДАМБЕРА И КЕМЕРЕРА-5 Метрика 5: Отклик для класса RFC (Response For a Class) Множество отклика класса RS множество методов, которые могут выполняться в ответ на прибытие сообщений в объект этого класса. где {R i } множество методов, вызываемых методом i, {М} множество всех методов в классе RFC - количество методов во множестве отклика, RFC = card{RS}. RFC количество методов класса плюс количество методов других классов, вызываемых из данного класса. Наихудшая величина отклика может использоваться при определении времени тестирования.

МЕТРИКИ ЧИДАМБЕРА И КЕМЕРЕРА-6 Метрика 6: Недостаток связности в методах LСOM (Lack of Cohesion in Methods) Каждый метод внутри класса обращается к одному или нескольким свойствам (экземплярным переменным). Метрика LCOM показывает, насколько методы не связаны друг с другом через свойства (переменные). Если все методы обращаются к одинаковым свойствам, то LCOM = 0. НЕ СВЯЗАНЫ количество пар методов без общих экземплярных переменных; СВЯЗАНЫ количество пар методов с общими экземплярными переменными. I j набор экземплярных переменных, используемых методом М j

МЕТРИКИ ЧИДАМБЕРА И КЕМЕРЕРА-6 LCOM это количество пар методов, не связанных по свойствам класса, минус количество пар методов, имеющих такую связь.

LCOM ПРИМЕР Пример 1: В классе имеются методы: M1, M2, М3, М4. Каждый метод работает со своим набором экземплярных переменных: I 1 ={a, b}; I 2 ={а, с}; I 3 ={х, у}; I 4 ={m, n}. НЕ СВЯЗАНЫ = card (I 13, I 14, I 23, I 24, I 34 ) = 5; СВЯЗАНЫ = card (I 12 ) = 1. LCOM = 5-1=4.

LCOM ПРИМЕР Пример 2: В классе используются методы: M1, M2, М3. Для каждого метода задан свой набор экземплярных переменных: I 1 = {a,b};I 2 ={a,c};I 3 ={x,y}, НЕ СВЯЗАНЫ = card (I 13, I 23 ) = 2; СВЯЗАНЫ = card (I 12 ) = 1, LCOM = 2- 1 = 1.

ИСПОЛЬЗОВАНИЕ МЕТРИК ЧИДАМБЕРА И КЕМЕРЕРА Имя класса WMCDITNOCСВОRFCLCOM Class A Class В Class С Class D Для вычисления метрики LCOM надо определить количество пар методов класса:

МЕТРИКИ ЛОРЕНЦА И КИДДА метрики размера подсчет свойств и операций для отдельных классов, а также их средних значений для всей ОО-системы метрики наследования способ повторного использования операций в иерархии классов внутренние метрики способ повторного использования операций в иерархии классов внешние метрики сцепление и повторное использование

МЕТРИКИ ЛОРЕНЦА И КИДДА -1 Метрика 1: Размер класса CS (Class Size) общее количество операций (вместе с приватными и наследуемыми экземплярными операциями), которые инкапсулируются внутри класса; количество свойств (вместе с приватными и наследуемыми экземплярными свойствами), которые инкапсулируются классом. Рекомендуемое значение CS до 20 методов.

МЕТРИКИ ЛОРЕНЦА И КИДДА -2,3 Метрика 2: Количество операций, переопределяемых подклассом, NOO (Number of Operations Overridden by a Subclass) Рекомендуемое значение NOO до 3 методов Метрика 3: Количество операций, добавленных подклассом, NOA (Number of Operations Added by a Subclass) Для рекомендуемых значений CS = 20 и DIT = 6 рекомендуемое значение NOA до 4 методов

МЕТРИКИ ЛОРЕНЦА И КИДДА -4 Метрика 4: Индекс специализации SI (Specialization Index) SI = (NOO x уровень) / M общ, где уровень номер уровня в иерархии, на котором находится подкласс, М общ общее количество методов класса. Рекомендуемое значение SI 0,15.

МЕТРИКИ ЛОРЕНЦА И КИДДА -5,6 Метрика 5: Средний размер операции OS AVG (Average Operation Size) количество строк программ или количество сообщений, посланных операцией Рекомендуемое значение OS AVG 9. Метрика 6: Сложность операции ОС (Operation Complexity) LOC, FP оценки, метрики Холстеда, цикломатическая сложность Рекомендуемое значение ОС 65 (для предложенного суммирования). ПараметрВес Вызовы функций API5,0 Присваивания0,5 Арифметические операции2,0 Сообщения с параметрами3,0 Вложенные выражения0,5 Параметры0,3 Простые вызовы7,0 Временные переменные0,5 Сообщения без параметров1,0

МЕТРИКИ ЛОРЕНЦА И КИДДА – 7,8 Метрика 7: Среднее количество параметров на операцию NP AVG (Average Number of Parameters per operation) Рекомендуемое значение NP AVG = 0,7 Метрика 8: Количество описаний сценариев NSS (Number of Scenario Scripts) Рекомендуемое значение NSS не менее одного сценария на публичный протокол подсистемы, отражающий основные функциональные требования к подсистеме.

МЕТРИКИ ЛОРЕНЦА И КИДДА – 9,10 Метрика 9: Количество ключевых классов NKC (Number of Key Classes) Рекомендуемое значение: если NKC < 0,2 от общего количества классов системы, следует углубить исследование проблемной области (для обнаружения важнейших абстракций, которые нужно реализовать). Метрика 10: Количество подсистем NSUB (NumberofSUBsystem) Рекомендуемое значение: NSUB > 3.

МЕТРИКИ ФЕРНАНДО АБРЕУ MOOD покрытие базовых механизмов объектно- ориентированной парадигмы, таких как инкапсуляция, наследование, полиморфизм, посылка сообщений; формальное определение метрик, позволяющее избежать субъективности измерения; независимость от размера оцениваемого программного продукта; независимость от языка программирования, на котором написан оцениваемый продукт.

МЕТРИКИ ФЕРНАНДО АБРЕУ фактор закрытости метода (МНF); фактор закрытости свойства (AHF); фактор наследования метода (MIF); фактор наследования свойства (AIF); фактор полиморфизма (POF); фактор сцепления (СОF).

МЕТРИКИ ДЛЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ТЕСТИРОВАНИЯ Р. БАЙНДЕРА Метрики инкапсуляции Метрика 1: Недостаток связности в методах LCOM Метрика 2: Процент публичных и защищенных свойств PAP (Percent Public and Protected) Метрика 3: Публичный доступ к компонентным данным PAD (Public Access to Data members) Метрики наследования Метрика 4: Количество корневых классов NOR (Number Of Root classes) Метрика 5: Коэффициент объединения по входу FIN (множественное наследование) Метрика 6: Количество детей NOC Метрика 7: Высота дерева наследования DIT

ЛІТЕРАТУРА Орлов С. А. Принципы объектно-ориентированного и параллельного программирования на языке Ada 95. Рига: TSI, с. Chidamber, S. R. and Kemerer, C. F. A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering, vol. 20: No. 6, June Gamma, E., Helm, R., Johnson, R., Vlissides, J. Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley, pp. Graham, I. Object-Oriented Methods. Principles & Practice. 3 rd Edition. Addison- Wesley, pp. Halstead, M. H. Elements of Software Science. New York, Elsevier North-Holland, Henry, S. and Kafura, D. Software Structure Metrics Based on Information Flow. IEEE Transactions on Software Engineering, vol. 7, No. 5,pp , Sept Hitz, M., Montazeri, В. Measuring Coupling in Object-Oriented Systems. Object Currents, vol. 2: 17 pp., No 4, Apr Lorenz, M. and Kidd, J. Object-Oriented Software Metrics. Prentice Hall, pp. Ott, L., Bieman, J. M., Kang, B-K., Mehra, B. Developing Measures of Class Cohesion for Object-Oriented Software. Proc. Annual Oregon Workshop on Software Merics (AOWSM'95). 11 pp., June 1995