Niniejszt artykuł przedstawia kompleksowe podejście do interpretacji i zastosowania metryk obiektowych, do mierzenia jakości oraz parametrów oprogramowania. Autor opisuje pojęcie metryki obiektowej, atrybutów które mierzy oraz korzyści jakie można uzyskać stosując ją w praktyce. Następnie wymienia ograniczenia związane z wykorzystaniem metryk oraz próby ich pokonania dzięki wizualizacji za pomocą perspektyw polimetrycznych i planów klas. Na koniec prezentuje przegląd popularnych narzędzi pokrycia kodu metrykami do języka Java.

1. Metryki obiektowe i ich interpretacja
Wojciech Podgórski
w.podgorski@student.pwr.wroc.pl
Abstrakt. PoniŜszy artykuł przedstawia kompleksowe podejście do
interpretacji i zastosowania metryk obiektowych, do mierzenia jakości oraz
parametrów oprogramowania. Autor opisuje pojęcie metryki obiektowej,
atrybutów które mierzy oraz korzyści jakie moŜna uzyskać stosując ją w
praktyce. Następnie wymienia ograniczenia związane z wykorzystaniem metryk
oraz próby ich pokonania dzięki wizualizacji za pomocą perspektyw
polimetrycznych i planów klas. Na koniec prezentuje przegląd popularnych
narzędzi pokrycia kodu metrykami do języka Java.
Słowa kluczowe: metryka obiektowa, perspektywa polimetryczna, plan klasy,
metryki Chidambera i Kemerera, metryki MOOD/MOOD2, metryki Martina,
projektowanie obiektowe, refaktoryzacja.
1 Wprowadzenie
Metryki obiektowe powstały w odpowiedzi na kompletny brak efektywności w ocenie
kodu pisanego zgodnie z paradygmatem obiektowości przez metryki strukturalne. Do
momentu powstania idei projektowania obiektowego, metryki takie jak złoŜoność
cyklomatyczna (CC), liczba linii kodu (LOC) czy zestaw metryk Halstead’a,
stanowiły podstawowe narzędzia oceny i weryfikacji kodu napisanego w języka
strukturalnych takich jak C czy Pascal. Wraz z spopularyzowaniem się paradygmatu
programowania obiektowego w latach 80-tych oraz na początku lat 90 i
powstawaniem języków zorientowanych obiektowo, zaczęło brakować efektywnych
środków ewaluacji tworzonych projektów. Metryki obiektowe rozwijane równolegle z
powstawaniem idei obiektowości stanowiły i stanowią efektywne narzędzia do oceny
tworzonych rozwiązań oraz sprawdzania jakości wykorzystania paradygmatu
obiektowego.
W celu lepszego zrozumienia metryk obiektowych, naleŜy wprowadzić pojęcie
metryki:
Def. Metryka jest to ilościowa miara stopnia w jakim system, komponent lub proces
posiada dany atrybut.
Źródło: IEEE
W odniesieniu do paradygmatu obiektowości, metryka jest miarą pewnego atrybutu
lub zbioru atrybutów. Zastosowanie metryk dla pewnej własności niesie ze sobą
informacje w postaci wyniku liczbowego. Informacja ta, sama w sobie jest
bezuŜyteczna, jeŜeli definicja metryki nie określa:

2. 1. W jaki sposób powinno się ją stosować, czyli algorytmu obliczania lub
wyznaczania wartości metryki dla poszczególnych atrybutów
2. Wartości oczekiwanych oraz granicznych, czyli interpretacji metryki, która
wskazuje w sposób zrozumiały istnienie problemu, ocenia wykorzystanie
mechanizmu lub określa prawidłowości związane z atrybutem.
3. W jaki sposób moŜe ona wpływać na poprawę jakości oprogramowania,
czyli relację pomiędzy metryką a konkretnymi jakościami oprogramowania
(ang. software qualities) takimi jak np. skalowalność, adaptacyjność,
niezawodność itp. oraz sposobu poprawy istniejącego kodu (refaktoryzacji)
w celu pozytywnego wpływu na jej wartość.
2 Zastosowanie metryk obiektowych
Metryki obiektowe słuŜą do weryfikacji stopnia uŜycia paradygmatu obiektowości w
procesie wytwarzania oprogramowania. Mierzą one kluczowe aspekty obiektowości
takie jak:
• Dziedziczenie (ang. inheritance), czyli relację pomiędzy modułami w której
moduł dziedziczący nabywa charakterystykę modułu (modułów) z którego
dziedziczy.
• Hermetyzację (ang. encapsulation), nazywaną równieŜ enkapsulacją
polegającą na ukrywaniu wewnętrznej struktury i złoŜoności modułu za
publicznym interfejsem.
• Polimorfizm (ang. polymorphism), będący mechanizmem pozwalającym na
przypisanie róŜnych typów temu samemu obiektowi.
• Powiązania (ang. coupling), czyli stopień w jakim jeden moduł zaleŜy od
innego (innych).
• Spójność (ang. cohesion), czyli stopień wewnętrznego powiązania i zakresu
odpowiedzialności danego modułu.
• ZaleŜności (ang. dependencies), czyli ilość, charakter i typ powiązań
istniejących pomiędzy modułami.
Metryki są niezwykle waŜnym i często niedocenionym narzędziem w wytwarzaniu
oprogramowania. W praktyce stosuje się je w niewielu projektach, a metody,
interpretacja oraz dobór odpowiednich metryk wciąŜ pozostawiają wiele do Ŝyczenia.
Typowym błędem popełnianym przez projektantów jest stosowanie metryk tylko w
ostatnich cyklach Ŝycia oprogramowania, np. w fazie testowania, bądź po kilku
iteracjach. Takie podejście jest błędne, poniewaŜ koszt związany z refaktoryzacją
kodu staje się coraz większy; ponadto metryki bardzo często wskazują na istnienie
pewnych problemów, które moŜna wyeliminować szybko i łatwo w początkowej fazie
rozwoju projektu. Łatwo więc zauwaŜyć, Ŝe jednym z podstawowych zastosowań
metryk obiektowych jest ukierunkowywanie refaktoryzacji. Na podstawie wartości
poszczególnych metryk moŜna wydedukować nie tylko błędy projektowe związane z
niepoprawną obiektowością, ale takŜe złe zapachy kodu (ang. bad smells). Ponadto,
niezwykle cenną informację niesie ze sobą interpretacja relacji pomiędzy wartościami

3. metryk. Niestety poprawne rozumienie takich związków wymaga od projektanta
ogromnego doświadczenia i niejednokrotnie związane jest ściśle z wykonywanym
projektem, nie odnajdując odzwierciedlenia w innym. Symptomy problemów
ukazywanych przez relacje pomiędzy metrykami oraz ich interpretacja są bardzo
dobrym gruntem do stosowania rozwiązań z zakresu sztucznej inteligencji. Prace
związane z metodami heurystycznymi w tej dziedzinie moŜna znaleźć w [4].
Metryki znajdują równieŜ ogromne zastosowanie w zarządzaniu złoŜonością, gdzie
złoŜoność rozumie się jako liczbę oraz charakter zaleŜności występujących pomiędzy
bytami w systemie. Kontrolowanie złoŜoności wytwarzanego oprogramowania jest
kluczowym aspektem umoŜliwiającym uzyskanie takich jakości jak skalowalność
(ang.scalability), zrozumiałość (ang. understandability) czy utrzymywalność (ang.
maintainability). W kaŜdym projekcie naleŜy dąŜyć do kontrolowania kaŜdej
poszczególnej zaleŜności występującej w systemie. Tylko zaleŜność której projektant
jest świadomy oraz w pełni rozumie jej sens, nie wpłynie negatywnie na złoŜoność
systemu. Aby utrzymać kontrolę zarówno nad system jak i jego przyszłym rozwojem,
naleŜy minimalizować liczbę występujących zaleŜności oraz dbać o to aby jej
przyrost był na stałym, co najwyŜej wielomianowym poziomie [7]. UŜycie metryk
sprowadza się tutaj do monitorowania istniejących zaleŜności na róŜnych poziomach
abstrakcji, wykrywania cykli zaleŜnościowych, badania abstrakcji/niestabilności
modułów, refaktoryzacji oraz projektowania powiązań.
Z pojęciem rozwoju systemu w kontekście zaleŜności, ale nie tylko, wiąŜe się kolejne
zastosowanie metryk, czyli estymacja kosztów i wielkości projektu. Tak jak zostało
wspomniane powyŜej, uŜycie metryk we wszystkich cyklach Ŝycia oprogramowania
oraz konfrontacja uzyskanych wartości z wynikami z poprzednich cyklów i projektów
pozwala na oszacowanie rozmiaru projektu i jego poszczególnych części, a co za tym
idzie estymację budŜetu, zarówno, czasowego, pienięŜnego, roboczego, a takŜe
jakościowego.
3 Metryki Chidambera i Kemerera
Zestaw ten został zaproponowany przez S.R. Chidambera i C.F. Kemerera w 1991
roku. Zaproponowali oni 6 metryk badających róŜne aspekty obiektowości, które
dotychczas nie były badane w kontekście pomiarów oprogramowania: złoŜoność
klasy, dziedziczenie, spójność, powiązania miedzy klasami.
Metryki z tego zestawu badają pojedyncze klasy i ich zbiory, zatem stanowią
narzędzie do niskopoziomowej oceny jakości kodu obiektowego [9].
RFC - Response For a Class (ang. odpowiedź klasy)
Określa liczbę komunikatów które moŜna wysłać do danej klasy. Jej wartość to suma
publicznych metod klasy i wszystkich jej podklas (lub implementacji tego interfejsu).
Wysoka wartość tej metryki wskazuje na duŜe wewnętrzne skomplikowanie klasy
oraz zbyt duŜą odpowiedzialność, jaką bierze na siebie ta klasa, co moŜe prowadzić
do wysokich kosztów jej testowania i pielęgnacji.
Dziedzina: RFC [0,∞)
Wartość oczekiwana: 20-100 [9]

4. DIT - Depth of Inheritance Tree (ang. głębokość drzewa dziedziczenia)
Określa maksymalna liczbę poziomów nadklas, z których rozpatrywana klasa
dziedziczy. Wysoka wartość DIT wskazuje, Ŝe klasa ta jest specjalizowana, o niskim
poziomie abstrakcji, oraz prawdopodobnie posiada wiele metod odziedziczonych po
przodkach. Z jednej strony wskazuje to na wysoki stopień powtórnego uŜycia kodu
poprzez dziedziczenie, ale z drugiej, moŜe ograniczać wykorzystanie innych
mechanizmów, np. kompozycji i wiązania klas przez referencje.
Dziedzina: DIT [0, ∞)
Wartość oczekiwana: 2-3[9], ≤ 5[10]
LCOM - Lack of Cohesion Of Methods (ang. brak spójności metod)
LCOM to metryka określająca spójność metod wewnątrz klasy. Mierzy brak odwołań
do wspólnych atrybutów klasy i przyjmuje wartość równą róŜnicy pomiędzy liczbą
metod odwołujących sie do wspólnego atrybutu klasy i liczbą metod o rozłącznych
zbiorach wykorzystywanych atrybutów. Spójność jest jedną z pozytywnych cech
związanych z klasą i oznacza, ze metody klasy są silnie związane ze sobą nawzajem i
polami zdefiniowanymi w tej klasie. Spójne klasy maja precyzyjnie określony obszar
odpowiedzialności i zwykle komunikują sie przez stosunkowo wąskie interfejsy.
Dziedzina: LCOM [0, ∞)
Wartość oczekiwana: 0[9]
CBO - Coupling Between Objects (ang. powiązania pomiędzy obiektami)
Metryka CBO zlicza liczbę klas związanych z klasą rozpatrywaną w sposób inny niŜ
poprzez dziedziczenie (a wiec jako atrybuty klasy, parametry metod, wartości
zwracane, klasy wyjątków itp.). Niski stopień powiązań klas miedzy sobą (ang.
coupling) wskazuje na ścisłe określenie granic pomiędzy klasami i sposobu ich
komunikowania się. Ponadto zwiększa stopień abstrakcji projektu, poniewaŜ łatwiej
modyfikować fragmenty kodu w nieznacznym stopniu zaleŜne od pozostałych.
Dziedzina: CBO [0, ∞)
Wartość oczekiwana: < 5[9]
WMC - Weighted Method per Class (ang. waŜona liczba metod w klasie)
WMC jest miarą złoŜoności klasy. W podstawowej wersji jest liczbą wszystkich
metod zdefiniowanych w klasie (czyli waga kaŜdej metody jest równa 1. W wersji
rozszerzonej wagi przypisywane metodom są obliczane na podstawie złoŜoności
cyklomatycznej McCabe’a). Metryka WMC pozwala na precyzyjniejszą ocenę niŜ
RFC, poniewaŜ uwzględnia złoŜoność kaŜdej metody.
Dziedzina: WMC [0, ∞)
Wartość oczekiwana: 0-100[9], 20-50[10], 10% wszystkich klas > 24 [10]
NOC - Number of Children (ang. liczba klas pochodnych)
NOC jest liczba bezpośrednich potomków danej klasy lub liczbą klas
implementujących dany interfejs. Wysoka wartość tej metryki wskazuje na
nieprawidłowa faktoryzację nadklasy lub interfejsu (jest ona wysoce abstrakcyjna i
prawdopodobnie obejmuje zbyt duŜy obszar odpowiedzialności), moŜe to powodować
trudności z jej pielęgnacją.
Dziedzina: NOC [0, ∞)

5. Wartość oczekiwana: -
4 Metryki MOOD/MOOD2
Metryki MOOD zostały zaproponowane przez F. B. e Abreu w 1995 roku. W skład
zestawu wchodzi 6 metryk charakteryzujących najbardziej widoczne elementy
projektu obiektowego: hermetyzację, dziedziczenie, polimorfizm, powiązania miedzy
klasami W roku 2001 autor wzbogacił zestaw o 4 kolejne metryki (MOOD2) badające
bardziej dogłębnie powyŜsze cechy. Metryki MOOD/MOOD2 są zdefiniowane jako
ilorazy rzeczywistego wykorzystania pewnego mechanizmu do maksymalnego
moŜliwego poziomu. Dzięki temu nie zaleŜą bezpośrednio od rozmiaru badanego
systemu i języka jego implementacji.
4.1 Metryki MOOD
AHF - Attribute Hiding Factor (ang. współczynnik ukrycia atrybutów)
AHF określa stopień hermetyzacji atrybutów klasy. Jest to stosunek liczby atrybutów
publicznych do wszystkich zdefiniowanych w klasie. Ograniczenie dostępu do klasy
wyłącznie do jej publicznych metod jest podstawowym mechanizmem hermetyzacji,
dlatego współczynnik AHF powinien przyjmować moŜliwe wysokie wartości.
Dziedzina: AHF [0,1]
Wartość oczekiwana: 1 (100%)[10]
MHF - Method Hiding Factor (ang. współczynnik ukrycia metod)
MHF określa stopień hermetyzacji metod klasy. Jest to stosunek liczby metod
publicznych do wszystkich zdefiniowanych w klasie. Metryka bada wewnętrzną
złoŜoność klasy. 100% wartość oznaczałaby, ze klasa jest całkowicie niedostępna dla
innych klas (tylko prywatne metody), a wiec nie mogą one sie z nią komunikować. Z
drugiej strony, oczywiście, kaŜda klasa zawiera grupę metod, które powinny być
ukryte i niedostępne.
Dziedzina: MHF [0,1]
Wartość oczekiwana: 0,1-0,4 (10-40%)[10]
AIF - Attribute Inheritance Factor (ang. współczynnik dziedziczenia atrybutów)
AIF określa wykorzystanie mechanizmu dziedziczenia i stanowi stosunek
odziedziczonych atrybutów do wszystkich atrybutów obecnych w klasie. Niska
wartość tej metryki wskazuje na niski stopień powtórnego wykorzystania kodu
poprzez dziedziczenie. Wartości zbliŜone do 100% oznaczają często zbyt
skomplikowane hierarchie dziedziczenia i naduŜycie tego mechanizmu.
Dziedzina: AIF [0,1]
Wartość oczekiwana: 0,4-0,8 (40-80%)[10]

6. MIF - Method Inheritance Factor (ang. współczynnik dziedziczenia metod)
MIF słuŜy do oceny stopnia wykorzystania mechanizmu dziedziczenia metod i
stanowi stosunek odziedziczonych metod do wszystkich zdefiniowanych w klasie.
Niska wartość tej metryki wskazuje na brak dziedziczenia lub wysoki stopień
przesłaniania metod. Wysoka wartość natomiast, na niepoprawnie uŜyty mechanizm
dziedziczenia i zbyt duŜa odpowiedzialność klasy.
Dziedzina: MIF [0,1]
Wartość oczekiwana: 0,6-0,8 (60-80%)[10]
PF - Polymorphism Factor (ang. współczynnik polimorficzności)
PF wskazuje, jaka część metod jest pokrywana w podklasach. Stanowi stosunek
metod pokrytych do wszystkich zdefiniowanych w klasie. Wartość PF powinna być
stosunkowo niska, ale wyŜsza od zera. Wartości bliskie zeru wskazują na strukturalny
projekt, który nie wykorzystuje moŜliwości języka obiektowego, natomiast wysokie –
na zbyt skomplikowane powiązania pomiędzy klasami i nieprawidłowa faktoryzację.
Dziedzina: PF [0,1]
Wartość oczekiwana: ~0,1 (~10%)[10]
CF - Coupling Factor (ang. współczynnik powiązań)
CF ocenia stopień zaleŜności poszczególnych klas od siebie. Pełni on podobną rolę
jak CBO z zestawu C&K, pozwalając określić stopień wypełnienia grafu zaleŜności.
Niska wartość wskazuje, ze odpowiedzialność jest nieprawidłowo podzielona
pomiędzy klasy i kilka z nich realizuje większość funkcjonalności. Wysoka wartość
CF sugeruje złe zaprojektowanie systemu, z wieloma zaleŜnościami pomiędzy
klasami, co znacznie ogranicza moŜliwości rozbudowy i podwyŜsza koszt pielęgnacji
kodu.
Dziedzina: CF [0,1]
Wartość oczekiwana: 0,05-0,2 (5-20%)[10]
4.2 Metryki MOOD2
AHEF - Attribute Hiding Effectiveness Factor (ang. współczynnik efektywności
ukrycia atrybutów)
AHEF ocenia stopień wykorzystania dostępności atrybutów. Jest to stosunek liczby
klas odwołujących sie do danego atrybutu do wszystkich klas w systemie, które mogą
sie do niego odwołać. AHEF jest kryterium metryki AHF. Im wyŜsza wartość
efektywności tym lepiej został określony zasięg widoczności atrybutu. Małe wartości
metryki wskazują na źle określony zasięg, atrybut widoczny dla zbyt wielu klas i
niepoprawne wykorzystanie mechanizmu hermetyzacji.
Dziedzina: AHEF [0,1]
Wartość oczekiwana: 1 (100%)[10]
OHEF - Operation Hiding Effectiveness Factor (ang. współczynnik efektywności
ukrycia operacji)
OHEF ocenia stopień wykorzystania dostępności operacji. Jest to stosunek liczby klas
wywołujących dana operacje (metodę) do wszystkich klas w systemie, które mogą ta

7. operacje wywołać. OHEF jest kryterium metryki MHF. Im wyŜsza wartość
efektywności tym lepiej został określony zasięg widoczności operacji. Małe wartości
metryki wskazują na źle określony zasięg, operację widoczną dla zbyt wielu klas i
niepoprawne wykorzystanie mechanizmu hermetyzacji.
Dziedzina: OHEF [0,1]
Wartość oczekiwana: 1 (100%)[10]
IIF - Internal Inheritance Factor (ang. współczynnik dziedziczenia wewnętrznego)
IIF określa stopień dziedziczenia wewnątrz systemu. Jest to stosunek liczby klas
dziedziczących z klas wewnątrz systemu do liczby klas dziedziczących z systemu
oraz bibliotek zewnętrznych. Niska wartość metryki wskazuje na wysoki stopień
ponownego uŜycia modułów zewnętrznych. Wysoka wartość wskazuje na to, ze
system definiuje własna hierarchie klas. JeŜeli IIF wynosi 0, to w systemie nie
występuje dziedziczenie wewnętrzne.
Dziedzina: IIF [0,1]
Wartość oczekiwana: zrównowaŜona
PPF - Parametric Polymorphism Factor (ang. współczynnik polimorfizmu
parametrycznego)
PPF określa stopień wykorzystania mechanizmu parametryzacji klas. Jest to stosunek
liczby klas sparametryzowanych (generycznych) do wszystkich klas występujących w
systemie. Wysoka wartość PPF wskazuje na bardzo generyczny i uniwersalny
charakter systemu oraz łatwość w jego rozbudowie i pielęgnacji. Niska wartość
wskazuje na bardzo wyspecjalizowany system z bardzo małymi moŜliwościami
ponownego uŜycia, trudny w pielęgnacji i rozbudowie.
Dziedzina: PPF [0,1]
Wartość oczekiwana: jak największa
5 Metryki R. Martina
Metryki autorstwa R. Martina, w odróŜnieniu od poprzednich dwóch zestawów,
przede wszystkim rozpatrują pojecie zaleŜności (powiązania) jednej klasy od drugiej.
Martin wyróŜnił zaleŜności do wewnątrz i na zewnątrz, co pozwoliło wskazać klasy
stanowiące rdzeń aplikacji i klasy wykonawcze, zaleŜne od tego rdzenia. Klasy takie
róŜnią się odpowiedzialnością i niezaleŜnością, dlatego w oparciu o te pojęcia
zdefiniowano następujące metryki:
Ca - Affarent coupling (ang. powiązania do wewnątrz)
Ca to liczba typów, które zaleŜą od rozpatrywanego modułu. Klasa o wysokiej
wartości tej metryki jest obciąŜona duŜą odpowiedzialnością wobec innych modułów,
co oznacza, ze zmiany w niej powodują konieczność modyfikacji zaleŜnych od niej
typów.
Dziedzina: Ca [0, ∞)
Wartość oczekiwana: jak najmniejsza

8. Ce - Efferent coupling (ang. powiązania na zewnątrz)
Ce określa zaleŜność rozpatrywanego modułu od modułów zewnętrznych. Wartością
tej metryki jest liczba typów, od których zaleŜy dany typ. Zmiany w klasach o
wysokiej wartości tej metryki w niewielkim stopniu wpływają na zewnętrzne moduły,
natomiast zmiany w nich z duŜym prawdopodobieństwem będą miały wpływ na
rozpatrywany moduł.
Dziedzina: Ce [0, ∞)
Wartość oczekiwana: jak najmniejsza
A - Abstractness (ang. abstrakcja)
A to miara abstrakcyjności pakietu, mierzona stosunkiem liczby typów
abstrakcyjnych wchodzących w skład tego pakietu do wszystkich typów. Klasy o
wysokim wskaźniku A trudno podlegają zmianom, poniewaŜ są odpowiedzialne
wobec typów zaleŜnych od nich.
Dziedzina: A [0,1]
Wartość oczekiwana: -
I - Instability (ang. niestabilność)
I jest miara niestabilności pakietu, czyli wpływu zewnętrznych typów na
rozpatrywaną klasę. Jest ona obliczana jako stosunek wartości metryki Ce do sumy
wszystkich zaleŜności (Ce + Ca). Wartości I bliskie jedynce sugerują, ze klasa jest
podatna na zmiany w zewnętrznych modułach (powiązania na zewnątrz stanowią
niemal 100% wszystkich powiązań), natomiast wartości bliskie zeru charakteryzują
klasę trudno poddającą się zmianom, z uwagi na ich wpływ na pozostałe typy.
Dziedzina: I [0,1]
Wartość oczekiwana: wartości ekstremalne (~0 lub ~1)
Dn - Normalized distance from main sequence (ang. znormalizowana odległość
od ciągu głównego)
Dn określa odległość od optymalnej linii łączącej punkty (1,0) i (0, 1) w układzie
współrzędnych metryk A i I. Klasy o niskiej wartości A powinny jednocześnie być
niestabilne – i na odwrót, poniewaŜ to świadczy o dobrej kompensacji tych dwóch
cech. Odchylenie od tej linii wskazuje na niepoprawne przypisanie odpowiedzialności
do danej klasy.
Dziedzina: Dn [0,1]
Wartość oczekiwana: 0
Rys.1. Ciąg główny w układzie abstrakcji/niestabilności.

9. 6 Problemy związane z stosowaniem metryk
Stosując metryki w procesie wytwarzania oprogramowania zawsze naleŜy pamiętać,
Ŝe są one tylko pomocnym narzędziem, a nie kryterium decydującym o dalszym
rozwoju projektu. Z uŜyciem metryk wiąŜą się pewne problemy, które muszą być
brane pod uwagę jeŜeli ich uŜycie ma być poprawne, wiarygodne i przynieść w pełni
pozytywny efekt. Bardzo częstym problemem występującym w projektach, w których
stosuje się metryki jest pokładanie stu procentowego zaufania w uzyskane rezultaty.
NaleŜy pamiętać o tym, Ŝe metryki to „tylko” liczby i nie moŜna wierzyć
bezgranicznie w ich wartości. Wyniki otrzymane po analizie bardzo często zaleŜą od
ogromnej liczby czynników, takŜe takich z których projektanci na początku nie zdają
sobie sprawy. Sytuacja taka moŜe doprowadzić do tego, Ŝe prawidłowo
zaprojektowany system moŜe dawać złe rezultaty liczbowe, a jednak działać lepiej i
stabilniej niŜ system, którego wyniki mieszczą się w wartościach oczekiwanych.
Wpływ na takie przypadki ma zastosowany język programowania (zupełnie inne
wartości oczekiwane i graniczne np. dla języka C++ i Ruby), rodzaj projektu
(projekty wykorzystujące gotowe komponenty lub framework’i w porównaniu do
projektów innowacyjnych, o duŜym ryzyku z bardzo zmiennymi wymaganiami), a
takŜe brak punktu odniesienia, czy teŜ kontekstu uzyskanych pomiarów (podawane w
literaturze przedziały wartości oczekiwanych i granicznych oparte są na intuicji,
doświadczeniu i wcześniejszych, niekoniecznie najlepszych projektach).
Drugim bardzo istotnym zagadnieniem jest to, Ŝe metryki pokazują symptomy
występującego problemu, a nie jego przyczynę. Mając uzyskaną wartość metryki,
która przekracza ustalone progi jesteśmy informowani o błędzie projektowym lub
implementacyjnym, lecz rzadko zdarza się tak, iŜ jego przyczyna jest banalna i moŜna
ją od razu wyeliminować. Interpretując wyniki zawsze naleŜy sprawdzać szerszy
kontekst niŜ obiekt na podstawie którego uzyskano rezultat. Interpretacja jednej
metryki moŜe okazać się niewystarczająca, niektóre problemy dają o sobie znać
poprzez ustalone wartości metryk i powiązania między nimi. Odnajdywanie i próba
zrozumienia takich relacji jest zadaniem niebanalnym i wymaga od projektanta
wiedzy oraz doświadczenia. Łatwo zatem zauwaŜyć, Ŝe poprawne stosowanie metryk
moŜe być trudne dla niedoświadczonych członków zespołu projektowego, a w
skrajnych przypadkach prowadzić nawet do niepoprawnej analizy skutkującej
kolejnymi błędami. Z racji powyŜszych trudności dobrą praktyką jest wyznaczenie
członka zespołu, który będzie odpowiedzialny za stosowanie metryk. Osoba ta
powinna cechować się nie tylko wiedzą i doświadczeniem w tym zakresie, ale
równieŜ obiektywnością oraz patrzeniem na system z odpowiednim dystansem.
7 Wizualizacje metryk
Próbą rozwiązania trudnej interpretacji metryk oraz związków, które między nimi
zachodzą są wizualizacje metryczne.

10. 7.1 Perspektywy polimet
polimetryczne
Perspektywy polimetryczne zostały opracowane przez Michele Lanza i Stephane
Ducasse i opublikowane w [2] oraz [4]. Jest to metoda graficznej wizualizacji metryk
oraz powiązań między nimi, w której wartości metryk prezentowane są poprzez
ędzy wane
wymiary, połoŜenie oraz kolor wyst
występujących encji, które odpowiadają modułom.
ą modułom
Metoda pozwala na wizualn charakterystykę systemu w kontekście klas i relacji oraz
wizualną cie
prostą i efektywną prezentację wartości metryk w skondensowany sposób.
prezentacj
(a) (b)
(c)
Rys.2. (a) Schemat perspektywy polimerycznej (b) Wizualizacja zaleŜności, klasa Project
ci,
posiadajacą 131 zaleŜno
Ŝności oraz zaleŜności cykliczne z klasami ProjectBrowser i
CoreFactory. Jakakolwiek zmiana w klasie Project moŜe prowadzić do ogromnych
problemów. (c) Trójwymiarowy widok polim
polimetryczny aplikacji ArgoUML (CodeCity) Klasy
(CodeCity).
ukazane jako budynki, powi
powiązania między nimi jako ścieŜki, pakiety jako dzielnice. Ź
Źródło: [4]
7.2 Plany klas
Plany klas (class blueprints) [3] to semantycznie bogata wizualizacja wewn
ycznie wewnętrznej
struktury klas oraz hierarchii do której nale
az naleŜą. Metoda okazuje sie być n
niezwykle

11. efektywna w wykrywaniu nieprawidłowości i anomalii implementacyjnych. Plany
klas stanowią rozwinięcie i dopełnienie idei perspektyw polimetrycznych. W
rozwini cie
metodzie tej klasa reprezentowana jest poprzez zbiór obszarów (inicjalizacji,
interfejsu zewnętrznego, wewnętrznej implementacji, akcesorów, atrybutów)
trznego, wewn ,
gromadzących metody, atrybuty i powiązania między nimi reprezentowane przez
cych powi dzy
bloki o określonych kolorach i wielkościach semantycznie odpowiadających
lonych wielko ciach odpowiadaj
ustalonym metrykom.
(a)
(b) (c)
Rys.3. (a) Schemat planu klasy (ang. class blueprint) (b) Wizualizacja polimetryczny hierarchii
planu klas ukazująca kilka problemów: Dziedziczenie potokowe - złe uŜycie mechanizmu
ca ycie
dziedziczenia i klas abstrakcyjnych. Podejrzana regularno regularność w liściach hierarchii:
ciach
zduplikowany kod. TreeModelComposite nie korzysta z odziedziczonych metod/atrybutów
metod/atrybutów.
(c) Plan klasy ukazujący klasę ModelFacade posiadająca 453 metody, 114 atrybutów, 3500
ący klas ca
linii kodu. Ukazana klasa jest typowym przykładem anomalii implementacyjnej nazywanej
God Class[4], którą moŜ rozpoznać poprzez uŜywanie przez klasę duŜej ilości atrybutów
moŜna ści
innych klas, bardzo wysok wartość metryki WMC oraz niską kohezję. Źródło: [4]
wysoką
8 Wybrane narzę
narzędzia
Do przygotowania niniejszego artykułu przetestowano trzy narzędzia pozwalające na
dzia pozwal
pokrycie kodu większo
ększością metryk prezentowanych powyŜej. W trakcie przegl
przeglądu

12. dostępnych narzędzi nie znaleziono Ŝadnego, który implementował by metryki z
zestawu MOOD2.
Do pokrycia kodu metrykami z zestawu CK wykorzystano aplikację ckjm -
Chidamber and Kemerer Java Metrics we wersji 1.8 (ckjm-1.8), opracowaną przez
Diomidis’a Spinellis’a. Aplikacja implementuje pomiar metryk WMC, DIT, NOC,
CBO, RFC, LCOM, oraz Ca (opis w metrykach Martina), NPM: Number of Public
Methods (liczba metod publicznych w klasie). Pokrycie kodu metrykami z zestawu
MOOD zostało zapewnione dzięki aplikacji OOMJ utworzonej przez Ayaz’a
Farooq’a. Aplikacja implementuje metryki AHF, MHF, AIF, MIF, PF, oraz wszystkie
metryki CK. Pokrycie metrykami Martina dokonano przy uŜyciu aplikacji JDepend w
wersji 2.9 (jdepend-2.9) opracowanej przez Mark’a Clark’a. Aplikacji implementuje
metryki Ca, Ce, A, I, Dn pozwala równieŜ na wykrywanie cykli oraz zlicza liczbę
klas i interfejsów.
9 Podsumowanie
Metryki obiektowe są bardzo waŜnym i często niedocenionym narzędziem w
projektowaniu i implementacji systemów zorientowanych obiektowo. Pozwalają na
wykrycie błędów implementacyjnych i projektowych, poprawienie ich poprzez
odpowiednią refaktoryzację, zarządzanie złoŜonością i utrzymanie poprawnej
obiektowości co prowadzi do osiągania poŜądanych jakości oprogramowania. NaleŜy
jednak pamiętać, Ŝe są to tylko kalkulacje liczbowe oparte na intuicji, doświadczeniu i
wcześniejszych, niekoniecznie najlepszych, projektach. Dlatego zawsze naleŜy
podchodzić do nich z dystansem i stosować je kierując sie zdrowym rozsądkiem.
Najbardziej popularnymi zestawami metryk są:
1. Metryki Chidambera i Kemerera
2. Metryki MOOD/MOOD2
3. Metryki Martina
Bibliografia
1. Kan S.H.: Metryki i modele w inŜynierii jakości oprogramowania. Wydawnictwo Naukowe
PWN SA, wydanie pierwsze (2006)
2. Lanza M., Ducasse S.: Polymetric Views-A Lightweight Visual Approach to Reverse
Engineering. IEEE Transactions on Software Engineering archive, Volume 29 , Issue 9,
pp. 782 - 795 (2003)
3. Lanza M., Ducasse S.: The Class Blueprint: Visually Supporting the Understanding of
Classes. IEEE Transactions on Software Engineering archive ,Volume 31, Issue 1, pp. 75-
90 (2005)
4. Lanza M., Marinescu R: Object-Oriented Metrics in Practice. Springer, 1st edition (2006)
5. Malminen S.: Object Metrics. Seminar on Software Engineering, Department of
Information Technology, University of Turku
6. Martin R.: OO Design Quality Metrics: An Analysis of Dependencies. Position paper, Proc.
Workshop Pragmatic and Theoretical Directions in Object-Oriented Software Metrics,
OOPSLA´94 (1994)

13. 7. Podgórski W.: Rola projektowania architektonicznego w inŜynierii oprogramowania
zorientowanej na usługi. Praca seminaryjna na przedmiot Projektowanie architektoniczne i
inŜynieria oprogramowania adaptacyjnych złoŜonych systemów, Instytut Informatyki
Politechniki Wrocławskiej, Wrocław (2009)
8. Rosenberg L.H.: Applying and Interpreting Object Oriented Metrics. Software Technology
Conference, Utah (1998)
9. Walter B.: Metryki obiektowe jako wskaźniki jakości kodu i projektu. Instytut Informatyki
Politechniki Poznańskiej
10. Object-oriented metrics, http://www.aivosto.com/project/help/pm-oo.html