WMC

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

${\displaystyle WMC=\sum \limits _{i=1}^{n}c_{i},}$

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

DIT

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].

NOC

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.

CBO

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.

RFC

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

${\displaystyle RFC=\sum \limits _{i=0}^{TM}M_{i}+\sum \limits _{i=0}^{TS}\sum \limits _{j=0}^{TC_{i}}M_{ij},}$

gdzie ${\displaystyle TM}$ oznacza całkowitą liczbę metod w klasie (total methods), ${\displaystyle TS}$ – liczbę podklas (total subclasses), a ${\displaystyle TC_{j}}$ – całkowitą liczbę metod w podklasie ${\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.

LCOM

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ć ${\displaystyle P}$ o 1, w przeciwnym razie należy zwiększyć ${\displaystyle Q}$ o 1. Wartością LCOM będzie ${\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:

${\displaystyle m}$ = liczba metod w klasie

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

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

${\displaystyle sum(mA)}$ = suma wartości ${\displaystyle mA}$ po wszystkich atrybutach

Wówczas ${\displaystyle LCOM2=1-{\tfrac {sum(mA)}{m\cdot a}},}$ a ${\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.

Efferent coupling

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 ${\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 ${\displaystyle Ce}$ jest interfejs użytkownika, który musi odzwierciedlać wszelkie zmiany w logice systemu.

Afferent coupling

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ść ${\displaystyle Ca,}$ tym więcej odpowiedzialności spoczywa na autorze zmian w kodzie danego komponentu. Wysokie ${\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.

Poziom niestabilności

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

${\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ść ${\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).

Poziom abstrakcji

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.

Odległość od ciągu głównego

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):

${\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ść ${\displaystyle D}$ powinna być niska, ponieważ współczynniki ${\displaystyle A}$ oraz ${\displaystyle I}$ powinny się wzajemnie kompensować, sumując się do 1. Wysoka wartość ${\displaystyle D}$ (powyżej 0,2) jest oznaką źle zaprojektowanego podziału klas.