Metryka oprogramowania

Metryka oprogramowania – miara pewnej własności oprogramowania lub jego specyfikacji. Termin ten nie ma precyzyjnej definicji i może oznaczać właściwie dowolną wartość liczbową charakteryzującą oprogramowanie^[1].

Standard IEEE 1061-1998 określa metrykę jako funkcję odwzorowującą jednostkę oprogramowania w wartość liczbową. Ta wyliczona wartość jest interpretowalna jako stopień spełnienia pewnej własności jakości jednostki oprogramowania^[2]. Metryki używają różnych definicji jednostki oprogramowania, opartej zazwyczaj na kodzie źródłowym, rozdzielonym na jeden lub więcej plików. Istnieją też metryki, które nie bazują na kodzie, lecz pozwalają na analizę specyfikacji oprogramowania (np. punkty funkcyjne) lub przebiegu wykonania programu.

Celem użycia metryk oprogramowania jest otrzymanie dokładnych wartości, które dotyczą wytwarzanych aplikacji. Lord Kelvin, fizyk i matematyk, stwierdził: Jeśli to o czym mówisz potrafisz zmierzyć i wyrazić w liczbach – wiesz coś o tym. Inaczej twa wiedza jest mizerna^[3], inżynier oprogramowania Tom DeMarco uważa zaś, że nie można kontrolować tego, czego się nie da zmierzyć^[4]. Metryki pozwalają na obiektywne spojrzenie na oprogramowanie i porównanie ze sobą poszczególnych jego elementów lub różnych produktów. Mierzenie jakości aplikacji oraz wydajności pracy bez danych liczbowych staje się bardzo trudne, a utrzymanie obiektywności jest niemal niemożliwe.

Obliczanie metryk jest istotnym ułatwieniem we wszystkich fazach procesu wytwarzania oprogramowania. W fazie projektowania metodologie takie jak COCOMO za pomocą rozmaitych metryk pozwalają na oszacowanie nakładu pracy potrzebnego do realizacji pomysłu. Na tym etapie metryki są przydatne przede wszystkim dla klientów oraz projektantów. W fazie produkcji dużą rolę odgrywają metryki statyczne, pomagające w utrzymywaniu jakości kodu źródłowego. Korzystają na tym programiści, którzy dzięki metrykom mogą łatwo odnajdywać te miejsca w kodzie, które są potencjalnym źródłem nadmiernej złożoności, a co za tym idzie, powstających błędów. W fazie testów wykorzystywane są zarówno metryki statyczne, jak i dynamiczne, pozwalające na badanie przebiegu wykonania programu. Na tym etapie gromadzone są też dane liczbowe dotyczące wydajności czy niezawodności aplikacji. Wyniki testów są pożytecznym źródłem informacji dla wszystkich osób zaangażowanych w projekt, w tym kierowników, programistów i klientów.

Istotną kwestią jest ocena samej metryki („meta-metryka”). Aby metryka była użyteczna, powinna być:

• prosta i możliwa do obliczenia przez komputer
• przekonująca
• konsekwentna i obiektywna
• spójna pod względem użytych jednostek
• niezależna od języka programowania
• dająca przydatne informacje^[5].

Linda Westfall wymienia 12 kroków prowadzących do opracowania użytecznych metryk:

1. identyfikacja klientów,
2. ustalenie celów,
3. zadanie pytań,
4. wybór metryk,
5. standaryzacja definicji,
6. wybór funkcji mierzącej,
7. ustalenie metody pomiaru,
8. definicja kryteriów wyboru,
9. definicja mechanizmów raportowania,
10. ustalenie dodatkowych własności,
11. zebranie danych,
12. aspekt ludzki^[1].

Charakterystycznym elementem jest paradygmat Cel – Pytanie – Metryka (GQM(inne języki), Goal – Question – Metrics), wypromowane przez Victora Basiliego z University of Maryland oraz Laboratorium Inżynierii Oprogramowania Centrum Lotów Kosmicznych imienia Roberta H. Goddarda. Polega ono na ustaleniu trzech kroków: pierwszym jest zdefiniowanie celów projektu, drugim ustalenie pytań, na które trzeba odpowiedzieć w trakcie realizacji, trzecim wykonanie odpowiednich pomiarów, dostosowanych odpowiednio do pierwszych dwóch poziomów^[6]. Metryka powinna być ściśle dopasowana do tego, jakie informacje są potrzebne w trakcie procesu tworzenia produktu. Używanie wyłącznie metryk ogólnych może być mylące, a nawet niebezpieczne^[7].

Podstawowy podział metryk oprogramowania związany jest ze sposobem podejścia do jego analizy i testowania. Podobnie jak testy dzielą się na testy strukturalne (testy białej skrzynki) oraz testy funkcjonalne (testy czarnej skrzynki), tak też można podzielić metryki na związane z analizą kodu źródłowego metryki statyczne oraz metryki dynamiczne, wyznaczane w oderwaniu od kodu i badające zachowanie uruchomionego programu. Osobną kategorią są metryki niezwiązane bezpośrednio z implementacją oprogramowania, lecz z jego specyfikacją, wymaganiami klienta, a także z przebiegiem testów.

Inne podejście dzieli metryki ze względu na obiekty i wartości je charakteryzujące, jakie są przez nie mierzone. Można wyróżnić metryki produktów, takie jak metryki rozmiaru (size metrics), metryki złożoności (complexity metrics) czy metryki jakości (quality metrics). Innymi metrykami są metryki procesów (process metrics), metryki zasobów (resource metrics) czy metryki projektu (project metrics)^[4]. Wyraźny jest tu podział na metryki produktów, dotyczące właściwości samego oprogramowania, oraz metryki procesów, charakteryzujące proces jego wytwarzania.

Metryki mogą mierzyć wartości bezpośrednio (np. liczba linii kodu) lub pośrednio, najpierw obliczając wartości składowe (np. częstość występowania błędów = liczba błędów / całkowity rozmiar produktu), mogą też bazować na subiektywnych prognozach (np. punkty funkcyjne)^[4].

Metryki statyczne pozwalają na ocenę jakości kodu źródłowego i łączą się ściśle z analizą statyczną, dziedziną inżynierii oprogramowania zajmującą się badaniem struktury kodu źródłowego. Metryki te najbardziej przydatne są dla samych programistów i innych osób bezpośrednio zaangażowanych w proces powstawania oprogramowania. Pozwalają na bieżące śledzenie jakości kodu i zwrócenie uwagi na miejsca, które wymagają uproszczenia bądź szczególnie uważnego testowania.

Najprostszą metryką rozmiaru oprogramowania jest liczba linii kodu źródłowego, oznaczana jako LOC (lines of code) lub SLOC (source lines of code). Wielkość ta daje ogólne pojęcie o skali programu, nie jest jednak wystarczająca do bardziej szczegółowych analiz. Wartość LOC jest silnie zależna od użytego języka programowania – ten sam algorytm w języku wysokiego poziomu będzie miał wielokrotnie mniej linii kodu niż w asemblerze.

Istotny jest też sposób zliczania linii kodu – ich liczba może się zdecydowanie zmieniać, zależnie od tego, czy wliczane są puste linie, komentarze czy linie zawierające jedynie nawiasy klamrowe (m.in. w językach C, Java czy PHP) bądź słowa kluczowe begin i end (w Pascalu). Liczba linii z pominięciem wymienionych elementów jest określana jako eLOC (effective lines of code).

Alternatywą dla zliczania fizycznych linii kodu jest miara logicznych linii kodu, oznaczana jako lLOC (logical lines of code). Miara ta jest zależna od użytego języka programowania, np. w C zliczane są linie zakończone średnikami^[8].

W większych projektach używane są jednostki pochodne takie jak KLOC (kilo-LOC).

Podstawową wadą liczby linii kodu jako metryki jest fakt, że nie odróżnia ona w żaden sposób trudnych i łatwych części kodu źródłowego oraz premiuje rozwlekły styl pisania programów. Aby nadać odpowiednie wagi mniej i bardziej skomplikowanym liniom kodu, można zastosować inną metrykę, mierzącą liczbę tokenów – czyli podstawowych jednostek składni języka programowania. Schemat takiej metryki został użyty po raz pierwszy w 1977 przez Maurice’a Howarda Halsteada w jego rodzinie metryk zwanej metrykami Halsteada^[9], a przez niego samego nazwanych Software Science. Halstead rozróżnił dwa typy tokenów, na które można podzielić całość kodu źródłowego (bez komentarzy). Są to operatory (symbole i słowa kluczowe symbolizujące pewną akcję) i operandy (zmienne, stałe itp.). Na ich podstawie można określić podstawowe metryki:

• η 1 {\displaystyle \eta _{1}} – liczba unikatowych operatorów
• η 2 {\displaystyle \eta _{2}} – liczba unikatowych operandów
• N 1 {\displaystyle N_{1}} – całkowita liczba wystąpień operatorów
• N 2 {\displaystyle N_{2}} – całkowita liczba wystąpień operandów.

Reguły klasyfikowania symboli jako operatorów i operandów są zależne od języka programowania. Na podstawie tych podstawowych wartości można określić kolejne, bardziej złożone:

• η = η 1 + η 2 {\displaystyle \eta =\eta _{1}+\eta _{2}} = słownictwo (vocabulary)
• N = N 1 + N 2 {\displaystyle N=N_{1}+N_{2}} = długość (length)
• V = N ⋅ log 2 ⁡ η {\displaystyle V=N\cdot \log _{2}{\eta }} = objętość (volume)^[9].

Badania wskazały, że wartości N i V są liniowo powiązane z liczbą linii kodu, mierzą więc tę samą wielkość. Charakteryzuje je jednak wyższa odporność na małe zmiany w kodzie. Halstead zaproponował też kolejne metryki, dotyczące już nie tylko rozmiaru, ale i złożoności programu, o których jest mowa poniżej.

Szeroko stosowane są jednostki rozmiaru programu większe niż linie kodu. Dla większych aplikacji często stosowanymi metrykami są liczba modułów czy liczba funkcji. Ponieważ obecnie dominującym paradygmatem programowania jest podejście obiektowe, wytworzono wiele metod mierzenia oprogramowania dla niego specyficznych (zob. metryki obiektowe). Podstawowymi metrykami rozmiaru dla projektów obiektowych są np. liczba klas i interfejsów.

Na podstawie linii kodu można wyliczyć wiele metryk pochodnych, takich jak produktywność (KLOC / osobomiesiąc), jakość (błędy / KLOC), koszt (koszt / KLOC) czy ilość dokumentacji (strony dokumentacji / KLOC)^[10]. Należy pamiętać, że zawsze będą one miały jedynie charakter pomocniczy i niedopuszczalne jest np. ocenianie pracowników wyłącznie na podstawie liczby napisanych linii kodu^[11].

Sam rozmiar programu jest informacją przydatną, jednak daje zbyt mało wiedzy na jego temat. Aby scharakteryzować oprogramowanie pod względem jego złożoności, trzeba użyć innych metod. Jeśli użyte są wyrafinowane algorytmy, cenną miarą będzie ich złożoność obliczeniowa. Wartość ta ma kluczowe znaczenie w badaniu wydajności, często daje jednak informacje o małym wycinku kodu źródłowego. Metryki mierzące złożoność opierają się na strukturze kodu źródłowego.

Jedną z najbardziej podstawowych metryk złożoności jest złożoność cyklomatyczna (cyclomatic complexity number, ozn. CC lub v(G)), zaproponowana przez Thomasa J. McCabe’a w 1976^[12]. Pierwotnie pomyślana była jako metryka dla programów strukturalnych, nadaje się jednak równie dobrze do programów obiektowych, dzięki czemu jest popularna także dzisiaj. Złożoność cyklomatyczna jest liczbą charakteryzującą funkcję lub metodę i odzwierciedlającą jej poziom skomplikowania.

Początkowo złożoność cyklomatyczna miała mierzyć liczbę niezależnych ścieżek przebiegu programu, co bezpośrednio przekłada się na łatwość jego przetestowania. Ponieważ skoki wstecz mogą spowodować nieskończony wzrost takich ścieżek, mierzy się liczbę prostych ścieżek bez uwzględniania cykli.

Złożoność cyklomatyczną dla danej funkcji można policzyć, mając do dyspozycji graf przebiegu programu. Wówczas wyraża się ona wzorem

v ( G ) = e − n + 2 , {\displaystyle v(G)=e-n+2,}

gdzie e {\displaystyle e} oznacza liczbę krawędzi, a n {\displaystyle n} liczbę wierzchołków w grafie. Inny wzór podaje prostą zależność CC od liczby węzłów, w których podejmujemy decyzje:

v ( G ) = d + 1 , {\displaystyle v(G)=d+1,}

gdzie d {\displaystyle d} to liczba węzłów decyzyjnych, w których podejmowana jest decyzja o charakterze binarnym (tak/nie).

Taki wzór pozwala na szybkie wyznaczanie wartości CC – wystarcza tu zliczyć liczbę wystąpień słów kluczowych if, while, for czy case.

Niska wartość CC wskazuje na łatwość zrozumienia danej funkcji czy metody. Wartość powyżej 20 charakteryzuje złożony kod i wiąże się z dużym ryzykiem wystąpienia błędów.

Zaletami metryki CC są m.in. łatwość jej obliczenia i możliwość wskazania elementów aplikacji, które należy przeprojektować. Liczba rozgałęzień przepływu programu nie daje jednak pełnej informacji, ponieważ nie rozróżnia zagnieżdżonych i niezagnieżdżonych pętli oraz prostych instrukcji case, a także nie bierze pod uwagę skomplikowanych warunków w węzłach decyzyjnych. Istnieją modyfikacje definicji CC, które pozwalają zredukować lub wyeliminować te wady^[13].

Wspomniane wyżej metryki Halsteada dotyczące rozmiaru programu pozwalają na zdefiniowanie bardziej skomplikowanych metryk złożoności. Wyróżnia się wśród nich:

D = η 1 2 ⋅ N 2 η 2 {\displaystyle D={\tfrac {\eta _{1}}{2}}\cdot {}{\tfrac {N_{2}}{\eta _{2}}}}	trudność (difficulty), czyli podatność na błędy, proporcjonalna do liczby unikatowych operatorów ( η 1 ) , {\displaystyle (\eta _{1}),} a także do stosunku pomiędzy wszystkimi ( N 2 ) {\displaystyle (N_{2})} a unikatowymi operandami ( η 2 ) {\displaystyle (\eta _{2})}
L = 1 D {\displaystyle L={\tfrac {1}{D}}}	poziom programu (program level), im niższy, tym bardziej aplikacja jest podatna na błędy
E = V ⋅ D {\displaystyle E=V\cdot D}	wysiłek (effort) potrzebny do zaimplementowania programu, proporcjonalny do trudności oraz objętości ( V = N ⋅ log 2 ⁡ η ) {\displaystyle (V=N\cdot \log _{2}{\eta })}
T = E 18 {\displaystyle T={\tfrac {E}{18}}}	czas (time) potrzebny do zaimplementowania, wyrażony w sekundach – współczynnik 18 został wyznaczony eksperymentalnie i jest modyfikowalny indywidualnie dla danego programisty
B = E 2 3 3000 {\displaystyle B={\tfrac {E^{\tfrac {2}{3}}}{3000}}}	szacunkowa liczba błędów (number of delivered bugs) – wartość ta jest zależna od użytego języka programowania, jest na przykład wyższa dla aplikacji w C lub C++

Niniejsze wartości mimo oczywistej niedokładności stanowią cenną informację podczas etapu testowania aplikacji – przykładowo wartość B {\displaystyle B} w porównaniu z rzeczywistą liczbą znalezionych błędów może dać wskazówki na temat efektywności przeprowadzonych testów.

Z powodu wzrostu popularności programowania obiektowego w latach 90. należało wprowadzić metryki adekwatne do tego podejścia.

Popularnym zestawem metryk jest grupa sześciu metryk autorstwa Shyama R. Chidambera i Chrisa F. Kemerera, zaprojektowana specjalnie dla oprogramowania obiektowego w 1991 i ulepszona w 1994^[14]. Od nazwisk autorów metryki te nazywane są zestawem metryk CK. Opisują one relacje pomiędzy klasami oraz ich złożoność i jej wpływ na utrzymywalność kodu. Ponieważ bazują one na analizie drzewa dziedziczenia oraz pojedynczych klas, nie nadają się do przewidywania czasu czy wysiłku koniecznego do implementacji, służą raczej projektantowi programiście jako informacje wskazujące potencjalne słabe punkty architektury systemu. Zestaw zawiera następujące metryki:

• Weighted Methods per Class (WMC)
• Depth of Inheritance Tree (DIT)
• Number of Children (NOC)
• Coupling Between Objects (CBO)
• Response For a Class (RFC)
• Lack of Cohesion of Methods (LCOM).

Metryka Weighted Methods per Class (WMC, tłum. na polski: uśrednione metody na klasę) zlicza metody występujące w danej klasie:

W M C = ∑ i = 1 n c i , {\displaystyle WMC=\sum \limits _{i=1}^{n}c_{i},}

gdzie c i {\displaystyle c_{i}} jest pewną miarą złożoności metody M i {\displaystyle M_{i}} ( M 1 , d o t s , {\displaystyle M_{1},dots,} M n {\displaystyle M_{n}} to kolejne metody w klasie). Jeśli za c i {\displaystyle c_{i}} wstawimy stałą 1, wynik będzie prostym zliczeniem wszystkich metod. W wariancie tej metryki za c i {\displaystyle c_{i}} należy wstawić złożoność cyklomatyczną danej metody.

Metryka Depth of Inheritance Tree (DIT, głębokość drzewa dziedziczenia) pozwala na określenie stopnia dziedziczenia – dla danej klasy wartością DIT jest liczba kolejnych klas, po których dziedziczy dana klasa. Jeśli występuje dziedziczenie wielokrotne, to wartością DIT jest najdłuższa ścieżka do korzenia (w przypadku języka Java korzeniem tym jest klasa Object, a wszystkie klasy mają DIT równe co najmniej 1).

Wynik tej metryki może być różnie interpretowany. Z jednej strony dziedziczenie pozwala na ponowne użycie kodu, z drugiej klasy o wysokim DIT mogą być przeładowane dziedziczonymi metodami. Rekomendowane jest DIT nieprzekraczające 6^[15].

Metryka Number of Children (NOC, liczba dzieci) polega na zliczaniu – w zależności od definicji – wszystkich lub tylko bezpośrednich podklas danej klasy. Podczas gdy DIT mierzy głębokość hierarchii dziedziczenia, NOC mierzy jej szerokość. Z powodu możliwości powtórnego użycia kodu lepsze jest głębokie drzewo dziedziczenia, dlatego wysoka wartość NOC może świadczyć o nieprawidłowym użyciu tego mechanizmu. Prawidłowe wartości NOC wahają się w przedziale od 2 do 5, wartości wyższe powodują problemy z pielęgnacją systemu.

Metryka Coupling Between Objects (CBO, zależność między obiektami) pozwala na określenie stopnia zależności klasy z innymi klasami niebędącymi jej przodkami ani klasami potomnymi. Jej wartością jest liczba odwołań do innych klas w obrębie metod i atrybutów danej klasy. Nie zalicza się tutaj odwołań do typów prymitywnych (int czy boolean) oraz podstawowych typów systemowych (w Javie: java.lang.*).

Wysoka wartość CBO wskazuje na nieprawidłowości – obiekty stają się wówczas zbyt zależne od innych.

Response For a Class (RFC, odpowiedzialność danej klasy) jest miarą potencjalnej komunikacji pomiędzy klasą a jej środowiskiem:

R F C = ∑ i = 0 T M M i + ∑ i = 0 T S ∑ j = 0 T C i M i j , {\displaystyle RFC=\sum \limits _{i=0}^{TM}M_{i}+\sum \limits _{i=0}^{TS}\sum \limits _{j=0}^{TC_{i}}M_{ij},}

gdzie T M {\displaystyle TM} oznacza całkowitą liczbę metod w klasie (total methods), T S {\displaystyle TS} – liczbę podklas (total subclasses), a T C j {\displaystyle TC_{j}} – całkowitą liczbę metod w podklasie j . {\displaystyle j.} Jest to więc liczba metod, które mogą potencjalnie zostać wysłane w odpowiedzi na dowolny komunikat wysłany do obiektu danej klasy. Wysoka wartość RFC oznacza większą funkcjonalność, ale zarazem i wyższą złożoność. Należy unikać zbyt wysokich wartości RFC, które zazwyczaj utrudniają weryfikację i testowanie klasy.

Lack of Cohesion of Methods (LCOM, brak spójności metod) jest metryką wskazującą na brak pożądanej własności klas, jaką jest ich spójność. Klasa powinna mieć ściśle określone pole działania i pełnić jedną dobrze wybraną funkcję. Brak spójności oznacza, że klasa wykonuje więcej niż jedną funkcję i powinna zostać podzielona, aby umożliwić prawidłową hermetyzację.

Występują cztery warianty metryki LCOM^[16]:

LCOM1 (Chidamber & Kemerer)

Pierwotna wersja metryki LCOM. Dla każdej pary metod w klasie sprawdzamy, czy mają one dostęp do rozłącznych zbiorów zmiennych instancyjnych. Jeśli tak jest, należy zwiększyć P {\displaystyle P} o 1, w przeciwnym razie należy zwiększyć Q {\displaystyle Q} o 1. Wartością LCOM będzie max ( P − Q , 0 ) . {\displaystyle \max(P-Q,0).}

Metryka LCOM1 była krytykowana ze względu m.in. na mało dokładne wyniki i błędne pojmowanie spójności klasy, dlatego zaproponowano kolejne wersje metryki.

LCOM2 oraz LCOM3 (Henderson-Sellers, Constantine & Graham)

Metryki LCOM2 i LCOM3, podobnie jak LCOM1, mierzą poziom spójności klasy i w nich także pożądana jest niska wartość. LCOM2 przyjmuje wartości z zakresu [0, 1], zaś LCOM3 z zakresu [0, 2]. W metrykach tych użyte są definicje:

m {\displaystyle m} = liczba metod w klasie

a {\displaystyle a} = liczba atrybutów w klasie

m A ( a ) {\displaystyle mA(a)} = liczba metod mających dostęp do atrybutu a {\displaystyle a}

s u m ( m A ) {\displaystyle sum(mA)} = suma wartości m A {\displaystyle mA} po wszystkich atrybutach

Wówczas L C O M 2 = 1 − s u m ( m A ) m ⋅ a , {\displaystyle LCOM2=1-{\tfrac {sum(mA)}{m\cdot a}},} a L C O M 3 = m − ( s u m ( m A ) ) a m − 1 . {\displaystyle LCOM3={\tfrac {\tfrac {m-(sum(mA))}{a}}{m-1}}.}

LCOM4 (Hitz & Montazeri)

Metryka LCOM4 pozwala na zmierzenie liczby spójnych składowych części klasy. Każda spójna składowa to pewien zbiór powiązanych ze sobą metod i atrybutów. Metody są ze sobą powiązane, jeśli mają dostęp do tego samego atrybutu lub jeśli jedna z nich wywołuje drugą.

Optymalną wartością LCOM4 jest 1. Wyższe wartości wskazują na konieczność podziału klasy, zaś wartość zerowa oznacza brak jakichkolwiek metod.

Zestaw MOOD (Metrics for Object-Oriented Design) został utworzony nieco później (1995) przez Fernando Brito e Abreu. Metryki te mają służyć całościowej ocenie systemu, a wyrażone są w procentach oznaczających stopień wykorzystania mechanizmów charakterystycznych dla programowania obiektowego. Zestaw MOOD jest niezależny od języka programowania oraz jest dobrze skalowalny.

Metryki MOOD mierzą następujące elementy:

• polimorfizm
  • Polymorphism Factor (PF)
• hermetyzacja
  • Attribute Hiding Factor (AHF)
  • Method Hiding Factor (MHF)
• dziedziczenie
  • Attribute Inheritance Factor (AIF)
  • Method Inheritance Factor (MIF)
• przekazywanie komunikatów
  • Coupling Factor (CF).

W późniejszym okresie powstały metryki MOOD2 – rozszerzenie standardowego zestawu MOOD. Wykorzystywane przez ten wariant metryki to:

• OHEF: Operation Hiding Effectiveness Factor
• AHEF: Attribute Hiding Effectiveness Factor
• IIF: Internal Inheritance Factor
• PPF: Parametric Polymorphism Factor^[17].

Metryki pakietów badają oprogramowanie na poziomie pakietów – służą do oceny prawidłowości ich powiązań.

Wartość metryki tree impurity (w wolnym tłumaczeniu „czystość drzewa”) powstaje na bazie grafu powiązań między poszczególnymi pakietami. Wartość ta waha się od 0 do 1 i wskazuje, jak bardzo graf jest zbliżony do drzewa. Wysokie tree impurity jest oznaką złego podziału oprogramowania na pakiety.

Jeśli jako e {\displaystyle e} oznaczymy liczbę krawędzi w grafie, a jako n {\displaystyle n} liczbę węzłów (pakietów), wartość metryki wyniesie 2 ⋅ e − n + 1 ( n − 1 ) ⋅ ( n − 2 ) . {\displaystyle 2\cdot {\tfrac {e-n+1}{(n-1)\cdot (n-2)}}.} Wartość 0% oznacza, że graf jest pełnym drzewem, zaś 100% – kliką.

Popularnym zestawem metryk pakietów jest grupa pięciu metryk zaprojektowana w 1994 przez Roberta Cecila Martina.

Metryka efferent coupling (w wolnym tłumaczeniu „zależność odśrodkowa”, także fan-out), oznaczana symbolem Ce, mierzy zależności wychodzące dla danej klasy lub danego pakietu. Jej wartość to liczba klas, od których rozpatrywany obiekt jest zależny. Miara ta wskazuje, które klasy i pakiety są najbardziej zależne od innych i tym samym narażone na niestabilność wobec zmian zachodzących w innych miejscach kodu. Optymalne wartości C e {\displaystyle Ce} wynoszą od 0 do 20, wyższe liczby powodują problemy związane z rozwojem i pielęgnacją danego komponentu. Przykładem elementów o wysokim C e {\displaystyle Ce} jest interfejs użytkownika, który musi odzwierciedlać wszelkie zmiany w logice systemu.

Metryka afferent coupling („zależność dośrodkowa”, fan-in, ozn. Ca) jest przeciwieństwem efferent coupling. Wartość ta oznacza liczbę klas, które są zależne od badanej klasy (pakietu). Im większa jest wartość C a , {\displaystyle Ca,} tym więcej odpowiedzialności spoczywa na autorze zmian w kodzie danego komponentu. Wysokie C a {\displaystyle Ca} w niejawny sposób oznacza wyższą stabilność, ponieważ wymusza ograniczenie zmian i wysoki poziom przetestowania. Liczba ta nie powinna przekraczać 500 – wyższe wartości sprawiają, że jakiekolwiek zmiany w elemencie stają się trudne do wykonania. Wysokim afferent coupling charakteryzują się np. kontrolery we wzorcu projektowym MVC.

Wartości C e {\displaystyle Ce} i C a {\displaystyle Ca} pozwalają wyznaczyć niestabilność (instability, ozn. I) danej klasy lub pakietu:

I = C e C e + C a . {\displaystyle I={\tfrac {Ce}{Ce+Ca}}.}

Niestabilność oznacza w tym wypadku podatność na zmiany w danym komponencie. Waha się ona pomiędzy 0 (dla elementów o wysokim afferent coupling) a 1 (dla elementów o wysokim efferent coupling). Według Roberta C. Martina klasy i pakiety dzielą się na dwie grupy – komponenty stabilne winny mieć wartość I {\displaystyle I} pomiędzy 0 a 0,3, natomiast niestabilne pomiędzy 0,7 a 1. Nie należy natomiast tworzyć klas i pakietów o średniej niestabilności (od 0,3 do 0,7).

Kolejną metryką związaną z własnościami pakietów jest poziom abstrakcji (abstractness, ozn. A). Wartość tej metryki to odsetek klas abstrakcyjnych w stosunku do wszystkich klas, znów wahający się pomiędzy 0 a 1. Wskazane jest, by to klasy abstrakcyjne cechowały się niskim poziomem niestabilności, ponieważ jest od nich zależnych wiele podklas.

Mając dane niestabilność i abstrakcyjność, możliwe jest obliczenie istotnego wskaźnika, jaką jest znormalizowana odległość od ciągu głównego (distance from main sequence, D):

D = A + I − 1. {\displaystyle D=A+I-1.}

Wartość ta odpowiada poziomowi zaburzenia równowagi pomiędzy poziomami abstrakcji i niestabilności. Klasy abstrakcyjne powinny charakteryzować się stabilnością, zaś niestabilne powinny być klasy konkretne. Dla dobrze zaprojektowanych klas wartość D {\displaystyle D} powinna być niska, ponieważ współczynniki A {\displaystyle A} oraz I {\displaystyle I} powinny się wzajemnie kompensować, sumując się do 1. Wysoka wartość D {\displaystyle D} (powyżej 0,2) jest oznaką źle zaprojektowanego podziału klas.

• zarządzanie przez jakość

• S.D. Conte, H.E. Dunsmore, V.Y. Shen: Software engineering metrics and models. Menlo Park, Kalifornia: The Benjamin/Cummings Publishing Company, Inc., 1986. ISBN 0-8053-2162-4.
• Cem Kaner, Walter P. Bond: Software Engineering Metrics: What Do They Measure and How Do We Know?. [dostęp 2009-06-13]. (ang.).
• Zaawansowana inżynieria oprogramowania. Wykłady w serwisie edukacyjnym Ważniak. [dostęp 2009-06-13].
• Zaawansowane programowanie obiektowe. Wykłady w serwisie edukacyjnym Ważniak. [dostęp 2009-06-14].
• Metrics Definitions – Resource Standard Metrics. [dostęp 2009-06-13]. [zarchiwizowane z tego adresu (23 czerwca 2006)]. (pol.).
• ckjm – A Tool for Calculating Chidamber and Kemerer Java Metrics. [dostęp 2009-11-04]. (ang.).
• Metrics Repository – kolekcja obiektowych metryk oprogramowania. [dostęp 2010-11-17]. (ang.).