Tekst źródłowy strony Metryka oprogramowania

{{Spis treści}}
'''Metryka oprogramowania''' – miara pewnej własności [[oprogramowanie|oprogramowania]] lub jego specyfikacji. Termin ten nie ma precyzyjnej definicji i może oznaczać właściwie dowolną wartość liczbową charakteryzującą oprogramowanie<ref name="12steps">{{Cytuj stronę |url= http://www.westfallteam.com/Papers/12_steps_paper.pdf |tytuł= 12 Steps to Useful Software Metrics |nazwisko= Westfall |imię= Linda |język= en |data dostępu= 2009-06-13}}</ref>.

Standard [[Instytut Inżynierów Elektryków i Elektroników|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''<ref>{{cytuj stronę |url= http://amutiara.staff.gunadarma.ac.id/Downloads/files/7082/IEEE+Standard+for+a+Software+Quality+Metrics+Methodology.pdf |tytuł= IEEE Std 1061-1998 (Revision of IEEE Std 1061-1992) |język= en |data dostępu= 2009-06-13}}</ref>. Metryki używają różnych definicji ''jednostki oprogramowania'', opartej zazwyczaj na [[kod źródłowy|kodzie źródłowym]], rozdzielonym na jeden lub więcej [[Plik danych|plików]]. Istnieją też metryki, które nie bazują na kodzie, lecz pozwalają na analizę specyfikacji oprogramowania (np. [[punkt funkcyjny|punkty funkcyjne]]) lub przebiegu wykonania programu.

== Zastosowanie ==
Celem użycia metryk oprogramowania jest otrzymanie dokładnych wartości, które dotyczą wytwarzanych aplikacji. [[William Thomson|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''<ref>Cyt. za: {{cytuj stronę |url= http://www.dbc.wroc.pl/Content/966/kacprzyk_c.pdf |tytuł= Wybrane zagadnienia badań ładunku i jego zaniku w dielektrykach stałych |nazwisko= Kacprzyk |imię= Ryszard |strony= 3 |data dostępu= 2009-06-13}}</ref>, inżynier oprogramowania [[Tom DeMarco]] uważa zaś, że nie można kontrolować tego, czego się nie da zmierzyć<ref name="finkelstein">{{cytuj stronę |url= http://www.cs.ucl.ac.uk/staff/A.Finkelstein/d22.html |tytuł= Advanced Software Engineering Course Structure |nazwisko= Finkelstein |imię= Anthony |opublikowany= University of London |język= en |data dostępu= 2009-06-13}}</ref>. 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 (informatyka)|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.

== Jakość metryki ==
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<ref>{{cytuj stronę |url= http://www.csse.monash.edu.au/~jonmc/CSE2305/Topics/07.14.SWEng2/html/text.html#what_is_a_metric |tytuł= Object-Oriented Software Engineering. Topic 14: Software Characteristics and Metrics |język= en |data dostępu= 2009-06-14}}</ref>.

Linda Westfall wymienia 12 kroków prowadzących do opracowania użytecznych metryk:
# identyfikacja klientów,
# ustalenie celów,
# zadanie pytań,
# wybór metryk,
# standaryzacja definicji,
# wybór funkcji mierzącej,
# ustalenie metody pomiaru,
# definicja kryteriów wyboru,
# definicja mechanizmów raportowania,
# ustalenie dodatkowych własności,
# zebranie danych,
# aspekt ludzki<ref name="12steps" />.
Charakterystycznym elementem jest paradygmat Cel – Pytanie – Metryka ({{Link-interwiki|GQM|Q=Q1533422}}, {{J|en|Goal}} – {{J|en|Question}} – {{J|en|Metrics}}), wypromowane przez Victora Basiliego z [[Uniwersytet Marylandu w College Park|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<ref>{{Cytuj stronę |url= http://www.eti.pg.gda.pl/katedry/kask/pracownicy/Jaroslaw.Kuchta/Jakosc/7b.GQM.ppt |tytuł= Jakość systemów informatycznych. Goal Question Metrics |nazwisko= Kuchta |imię= Jarosław |język= pl |data dostępu= 2009-06-13 |archiwum= https://web.archive.org/web/20101009063044/http://www.eti.pg.gda.pl/katedry/kask/pracownicy/Jaroslaw.Kuchta/Jakosc/7b.GQM.ppt |zarchiwizowano= 9 października 2010 }}</ref>. 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<ref name="subieta">{{cytuj stronę |url= http://pjwstk.wafel.com/wyt/Wykw1314.pdf |tytuł= Wytwarzanie, integracja i testowanie systemów informacyjnych. Jakość, złożoność i miary oprogramowania |nazwisko= Subieta |imię= Kazimierz |data dostępu= 2009-06-13 |archiwum= https://web.archive.org/web/20060721212214/http://pjwstk.wafel.com/wyt/Wykw1314.pdf |zarchiwizowano= 21 lipca 2006 }}</ref>.

== Podział ==
Podstawowy podział metryk oprogramowania związany jest ze sposobem podejścia do jego [[analiza programów|analizy]] i [[testowanie oprogramowania|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 [[implementacja (informatyka)|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 ({{K|en|size metrics}}), metryki złożoności ({{K|en|complexity metrics}}) czy metryki jakości ({{K|en|quality metrics}}). Innymi metrykami są metryki procesów ({{K|en|process metrics}}), metryki zasobów ({{K|en|resource metrics}}) czy metryki projektu ({{K|en|project metrics}})<ref name="finkelstein" />. 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)<ref name="finkelstein" />.

== Metryki statyczne ==
Metryki statyczne pozwalają na ocenę jakości kodu źródłowego i łączą się ściśle z [[analiza statyczna|analizą statyczną]], dziedziną [[inżynieria oprogramowania|inżynierii oprogramowania]] zajmującą się badaniem struktury kodu źródłowego. Metryki te najbardziej przydatne są dla samych [[programista|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.

=== Metryki rozmiaru ===
==== Linie kodu ====
[[Plik:CodeCmmt002.svg|thumb|300px|Przykładowy kod w Javie: wszystkich LOC jest 18, bez pustych linii 16, bez komentarzy 9, bez nawiasów 8]]
{{osobny artykuł|linia kodu}}
Najprostszą metryką rozmiaru oprogramowania jest liczba linii kodu źródłowego, oznaczana jako '''{{J|en|LOC}}''' ({{K|en|lines of code}}) lub {{J|en|SLOC}} ({{K|en|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ść {{J|en|LOC}} jest silnie zależna od użytego [[język programowania|języka programowania]] – ten sam algorytm w [[język wysokiego poziomu|języku wysokiego poziomu]] będzie miał wielokrotnie mniej linii kodu niż w [[asembler]]ze.

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

Alternatywą dla zliczania ''fizycznych'' linii kodu jest miara ''logicznych'' linii kodu, oznaczana jako '''{{J|en|lLOC}}''' ({{K|en|logical lines of code}}). Miara ta jest zależna od użytego języka programowania, np. w C zliczane są linie zakończone średnikami<ref>{{cytuj stronę |url= http://www.knowledgerush.com/kr/encyclopedia/Source_lines_of_code/ |tytuł= Source lines of code – Knowledgerush |język=en |data dostępu= 2009-06-13}}</ref>.

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

==== Liczba tokenów ====
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 [[metryki Halsteada|metrykami Halsteada]]<ref name="halstead">{{cytuj stronę |url= http://www.verifysoft.com/en_halstead_metrics.html |tytuł= Halstead metrics |język= en |data dostępu= 2009-06-14}}</ref>, 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 [[operator (programowanie)|operatory]] (symbole i słowa kluczowe symbolizujące pewną akcję) i [[operand]]y ([[zmienna (informatyka)|zmienne]], [[stała (informatyka)|stałe]] itp.). Na ich podstawie można określić podstawowe metryki:
* <math>\eta_1</math> – liczba unikatowych operatorów
* <math>\eta_2</math> – liczba unikatowych operandów
* <math>N_1</math> – całkowita liczba wystąpień operatorów
* <math>N_2</math> – 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:
* <math>\eta = \eta_1 + \eta_2</math>   = słownictwo ({{K|en|vocabulary}})
* <math>N = N_1 + N_2</math>            = długość    ({{K|en|length}})
* <math>V = N \cdot \log_2{\eta}</math> = objętość   ({{K|en|volume}})<ref name="halstead" />.

Badania wskazały, że wartości {{Mvar|N}} i {{Mvar|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 [[#Złożoność Halsteada|poniżej]].

==== Inne metryki ====
Szeroko stosowane są jednostki rozmiaru programu większe niż linie kodu. Dla większych aplikacji często stosowanymi metrykami są liczba [[moduł (informatyka)|modułów]] czy liczba [[podprogram|funkcji]]. Ponieważ obecnie dominującym paradygmatem programowania jest podejście [[programowanie obiektowe|obiektowe]], wytworzono wiele metod mierzenia oprogramowania dla niego specyficznych (zob. [[#Metryki obiektowe|metryki obiektowe]]). Podstawowymi metrykami rozmiaru dla projektów obiektowych są np. liczba [[klasa (programowanie obiektowe)|klas]] i [[Interfejs (programowanie obiektowe)|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)<ref>{{Cytuj stronę |url= http://hebb.cis.uoguelph.ca/~dave/27320/new/metrics.html |tytuł= Software metrics |język= en |data dostępu= 2009-06-14 |archiwum= https://web.archive.org/web/20081021043926/http://hebb.cis.uoguelph.ca/~dave/27320/new/metrics.html |zarchiwizowano= 21 października 2008 }}</ref>. 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<ref>Por. np. {{cytuj stronę |url= http://faculty.ksu.edu.sa/ghazy/Cost_MSc/R8.PDF |tytuł= Resource Estimation in Software Engineering |nazwisko= Brand |imię= Lionel C. |nazwisko2= Wieczorek |imię2= Isabella |strony= 36 |data dostępu= 2009-06-14 |archiwum= https://web.archive.org/web/20130617040506/http://faculty.ksu.edu.sa/ghazy/Cost_MSc/R8.PDF |zarchiwizowano= 17 czerwca 2013 }}</ref>.

=== Podstawowe metryki złożoności ===
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 [[algorytm]]y, cenną miarą będzie ich [[złożoność obliczeniowa]]. Wartość ta ma kluczowe znaczenie w badaniu [[wydajność oprogramowania|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.

==== Złożoność cyklomatyczna McCabe’a ====
[[Plik:Flowchart example.png|thumb|200px|Przykład funkcji o niskim CC:<br />8 węzłów, 8 krawędzi,<br />CC = 8 – 8 + 2 = 2]]
{{osobny artykuł|złożoność cyklomatyczna}}
Jedną z najbardziej podstawowych metryk złożoności jest złożoność cyklomatyczna ({{K|en|cyclomatic complexity number}}, ozn. CC lub v(G)), zaproponowana przez Thomasa J. McCabe’a w 1976<ref>{{cytuj stronę |url= http://www.literateprogramming.com/mccabe.pdf |tytuł= A Complexity Measure |nazwisko= McCabe |imię= Thomas J. |język=en |data dostępu= 2009-06-14}}</ref>. 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 [[metoda (programowanie obiektowe)|metodę]] i odzwierciedlającą jej poziom skomplikowania.

Początkowo złożoność cyklomatyczna miała mierzyć liczbę niezależnych [[ścieżka (teoria grafów)|ś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 [[cykl (teoria grafów)|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
: <math>v(G) = e - n + 2,</math>

gdzie <math>e</math> oznacza liczbę krawędzi, a <math>n</math> liczbę wierzchołków w grafie. Inny wzór podaje prostą zależność CC od liczby węzłów, w których podejmujemy decyzje:
: <math>v(G) = d + 1,</math>

gdzie <math>d</math> 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 <code>if</code>, <code>while</code>, <code>for</code> czy <code>case</code>.

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 <code>case</code>, 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<ref>{{cytuj stronę |url= http://www.aivosto.com/project/help/pm-complexity.html |tytuł= Complexity metrics |język= en |data dostępu= 2009-06-14}}</ref>.

==== Złożoność Halsteada ====
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:
{|
| style="padding-right:10px"| <math>D = \tfrac{\eta_1}{2} \cdot{} \tfrac{N_2}{\eta_2}</math>
| trudność ({{K|en|difficulty}}), czyli podatność na błędy, proporcjonalna do liczby unikatowych operatorów <math>(\eta_1),</math> a także do stosunku pomiędzy wszystkimi <math>(N_2)</math> a unikatowymi operandami <math>(\eta_2)</math>
|-
| <math>L = \tfrac{1}{D}</math>
| poziom programu ({{K|en|program level}}), im niższy, tym bardziej aplikacja jest podatna na błędy
|-
| <math>E = V \cdot D</math>
| wysiłek ({{K|en|effort}}) potrzebny do zaimplementowania programu, proporcjonalny do trudności oraz objętości <math>(V = N \cdot \log_2{\eta})</math>
|-
| <math>T = \tfrac{E}{18}</math>
| czas ({{K|en|time}}) potrzebny do zaimplementowania, wyrażony w sekundach – współczynnik 18 został wyznaczony eksperymentalnie i jest modyfikowalny indywidualnie dla danego programisty
|-
| <math>B = \tfrac{E^\tfrac{2}{3}}{3000}</math>
| szacunkowa liczba błędów ({{K|en|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 (język programowania)|C]] lub [[C++]]
|}

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

=== Metryki obiektowe ===
Z powodu wzrostu popularności [[programowanie obiektowe|programowania obiektowego]] w latach 90. należało wprowadzić metryki adekwatne do tego podejścia.

==== Zestaw metryk CK ====
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<ref>{{cytuj stronę |url= http://www.cs.auckland.ac.nz/compsci702s1c/lectures/ewan/cs702-notes-lec08-ck.pdf |tytuł= The „CK” Metrics |nazwisko= Tempero |imię= Ewan |nazwisko2= Mendes |imię2= Emilia |język= en |data dostępu= 2009-06-14 |archiwum= https://web.archive.org/web/20100331064300/http://www.cs.auckland.ac.nz/compsci702s1c/lectures/ewan/cs702-notes-lec08-ck.pdf |zarchiwizowano= 31 marca 2010 }}</ref>. Od nazwisk autorów metryki te nazywane są zestawem metryk CK. Opisują one relacje pomiędzy [[klasa (programowanie obiektowe)|klasami]] oraz ich złożoność i jej wpływ na utrzymywalność kodu. Ponieważ bazują one na analizie drzewa [[dziedziczenie (programowanie)|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:
* {{J|en|Weighted Methods per Class}}  ({{J|en|WMC}})
* {{J|en|Depth of Inheritance Tree}}   ({{J|en|DIT}})
* {{J|en|Number of Children}}          ({{J|en|NOC}})
* {{J|en|Coupling Between Objects}}    ({{J|en|CBO}})
* {{J|en|Response For a Class}}        ({{J|en|RFC}})
* {{J|en|Lack of Cohesion of Methods}} ({{J|en|LCOM}}).

===== {{J|en|WMC}} =====
Metryka '''{{J|en|Weighted Methods per Class}}''' ({{J|en|WMC}}, tłum. na polski: ''uśrednione metody na klasę'') zlicza [[metoda (programowanie obiektowe)|metody]] występujące w danej klasie:
: <math>WMC = \sum\limits_{i=1}^n c_i,</math>

gdzie <math>c_i</math> jest pewną miarą złożoności metody <math>M_i</math> (<math>M_1,dots,</math> <math>M_n</math> to kolejne metody w klasie). Jeśli za <math>c_i</math> wstawimy stałą 1, wynik będzie prostym zliczeniem wszystkich metod. W wariancie tej metryki za <math>c_i</math> należy wstawić złożoność cyklomatyczną danej metody.

===== {{J|en|DIT}} =====
Metryka '''{{J|en|Depth of Inheritance Tree}}''' ({{J|en|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 (programowanie)#Dziedziczenie wielokrotne|dziedziczenie wielokrotne]], to wartością DIT jest najdłuższa ścieżka do korzenia (w przypadku języka Java korzeniem tym jest klasa <code>Object</code>, 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<ref name="ndepend">{{cytuj stronę |url= http://www.ndepend.com/Metrics.aspx |tytuł= NDepend. Metrics definitions |język= en |data dostępu= 2009-06-14}}</ref>.

===== {{J|en|NOC}} =====
Metryka '''{{J|en|Number of Children}}''' ({{J|en|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.

===== {{J|en|CBO}} =====
Metryka '''{{J|en|Coupling Between Objects}}''' ({{J|en|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 (<code>int</code> czy <code>boolean</code>) oraz podstawowych typów systemowych (w Javie: <code>java.lang.*</code>).

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

===== {{J|en|RFC}} =====
'''{{J|en|Response For a Class}}''' ({{J|en|RFC}}, ''odpowiedzialność danej klasy'') jest miarą potencjalnej komunikacji pomiędzy klasą a jej środowiskiem:
: <math>RFC = \sum\limits_{i=0}^{TM}M_i + \sum\limits_{i=0}^{TS} \sum\limits_{j=0}^{TC_i}M_{ij},</math>

gdzie <math>TM</math> oznacza całkowitą liczbę metod w klasie (''total methods''), <math>TS</math> – liczbę podklas (''total subclasses''), a <math>TC_j</math> – całkowitą liczbę metod w podklasie <math>j.</math> 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.

===== {{J|en|LCOM}} =====
'''{{J|en|Lack of Cohesion of Methods}}''' ({{J|en|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ą [[Hermetyzacja (informatyka)|hermetyzację]].

Występują cztery warianty metryki LCOM<ref>{{cytuj stronę |url= http://www.aivosto.com/project/help/pm-oo-cohesion.html |tytuł= Cohesion metrics |język= en |data dostępu= 2009-06-14}}</ref>:
; LCOM1 (Chidamber & Kemerer)
: Pierwotna wersja metryki LCOM. Dla każdej pary metod w klasie sprawdzamy, czy mają one dostęp do [[zbiory rozłączne|rozłącznych zbiorów]] zmiennych instancyjnych. Jeśli tak jest, należy zwiększyć <math>P</math> o 1, w przeciwnym razie należy zwiększyć <math>Q</math> o 1. Wartością LCOM będzie <math>\max(P-Q, 0).</math>
: 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:
:: <math>m</math> = liczba metod w klasie
:: <math>a</math> = liczba atrybutów w klasie
:: <math>mA(a)</math> = liczba metod mających dostęp do atrybutu <math>a</math>
:: <math>sum(mA)</math> = suma wartości <math>mA</math> po wszystkich atrybutach
: Wówczas <math>LCOM2 = 1-\tfrac{sum(mA)}{m \cdot a},</math> a <math>LCOM3 = \tfrac{\tfrac{m-(sum(mA))}{a}}{m-1}.</math>
; LCOM4 (Hitz & Montazeri)
: Metryka LCOM4 pozwala na zmierzenie liczby [[spójna składowa grafu|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.

{{Zobacz też|spójność oprogramowania}}

==== Zestaw metryk {{J|en|MOOD}} ====
Zestaw {{J|en|MOOD}} ({{J|en|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 (informatyka)|polimorfizm]]
** {{J|en|Polymorphism Factor}}          ({{J|en|PF}})
* [[Hermetyzacja (informatyka)|hermetyzacja]]
** {{J|en|Attribute Hiding Factor}}      ({{J|en|AHF}})
** {{J|en|Method Hiding Factor}}         ({{J|en|MHF}})
* [[dziedziczenie (programowanie)|dziedziczenie]]
** {{J|en|Attribute Inheritance Factor}} ({{J|en|AIF}})
** {{J|en|Method Inheritance Factor}}    ({{J|en|MIF}})
* przekazywanie komunikatów
** {{J|en|Coupling Factor}}              ({{J|en|CF}}).

W późniejszym okresie powstały metryki MOOD2 – rozszerzenie standardowego zestawu MOOD. Wykorzystywane przez ten wariant metryki to:
* {{J|en|OHEF}}: Operation Hiding Effectiveness Factor
* {{J|en|AHEF}}: Attribute Hiding Effectiveness Factor
* {{J|en|IIF}}:  Internal Inheritance Factor
* {{J|en|PPF}}:  Parametric Polymorphism Factor<ref>{{cytuj stronę |url= http://www.aivosto.com/project/help/pm-oo-mood.html |tytuł= MOOD and MOOD2 metrics |język=en |data dostępu= 2009-06-14}}</ref>.

=== Metryki pakietów ===
Metryki pakietów badają oprogramowanie na poziomie [[moduł (informatyka)|pakietów]] – służą do oceny prawidłowości ich powiązań.

==== {{J|en|Tree impurity}} ====
Wartość metryki {{K|en|tree impurity}} (w wolnym tłumaczeniu „czystość drzewa”) powstaje na bazie [[Graf (matematyka)|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 {{K|en|tree impurity}} jest oznaką złego podziału oprogramowania na pakiety.

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

==== Metryki Roberta C. Martina ====
Popularnym zestawem metryk pakietów jest grupa pięciu metryk zaprojektowana w 1994 przez [[Robert Cecil Martin|Roberta Cecila Martina]].

===== {{J|en|Efferent coupling}} =====
Metryka {{K|en|efferent coupling}} (w wolnym tłumaczeniu „zależność odśrodkowa”, także {{K|en|fan-out}}), oznaczana symbolem '''{{J|en|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 <math>Ce</math> 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 <math>Ce</math> jest [[interfejs użytkownika]], który musi odzwierciedlać wszelkie zmiany w logice systemu.
{{Zobacz też|zależność oprogramowania}}

===== {{J|en|Afferent coupling}} =====
Metryka {{K|en|afferent coupling}} („zależność dośrodkowa”, {{K|en|fan-in}}, ozn. '''{{J|en|Ca}}''') jest przeciwieństwem {{K|en|efferent coupling}}. Wartość ta oznacza liczbę klas, które są zależne od badanej klasy (pakietu). Im większa jest wartość <math>Ca,</math> tym więcej odpowiedzialności spoczywa na autorze zmian w kodzie danego komponentu. Wysokie <math>Ca</math> 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 {{J|en|afferent coupling}} charakteryzują się np. kontrolery we wzorcu projektowym [[Model-View-Controller|MVC]].

===== Poziom niestabilności =====
Wartości <math>Ce</math> i <math>Ca</math> pozwalają wyznaczyć niestabilność ({{K|en|instability}}, ozn. '''{{J|en|I}}''') danej klasy lub pakietu:
: <math>I = \tfrac{Ce}{Ce + Ca}.</math>

Niestabilność oznacza w tym wypadku podatność na zmiany w danym komponencie. Waha się ona pomiędzy 0 (dla elementów o wysokim {{J|en|afferent coupling}}) a 1 (dla elementów o wysokim {{J|en|efferent coupling}}). Według Roberta C. Martina klasy i pakiety dzielą się na dwie grupy – komponenty stabilne winny mieć wartość <math>I</math> 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 ({{K|en|abstractness}}, ozn. '''{{J|en|A}}'''). Wartość tej metryki to odsetek [[klasa abstrakcyjna|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 ({{K|en|distance from main sequence}}, '''{{J|en|D}}'''):
: <math>D = A + I - 1.</math>

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

== Zobacz też ==
* [[zarządzanie przez jakość]]

== Przypisy ==
{{Przypisy}}

== Bibliografia ==
* {{cytuj książkę |nazwisko=Conte |imię=S.D. |tytuł=Software engineering metrics and models |wydawca=The Benjamin/Cummings Publishing Company, Inc. |miejsce=Menlo Park, Kalifornia |data=1986 |isbn=0-8053-2162-4 |nazwisko2=Dunsmore |imię2=H.E. |nazwisko3=Shen |imię3=V.Y.}}
* {{cytuj stronę |url= http://www.kaner.com/pdfs/metrics2004.pdf |tytuł= Software Engineering Metrics: What Do They Measure and How Do We Know? |nazwisko= Kaner |imię= Cem |nazwisko2= Bond |imię2= Walter P. |język= en |data dostępu= 2009-06-13}}
* {{cytuj stronę |url= http://wazniak.mimuw.edu.pl/index.php?title=Zio-6a-wyk-toc |tytuł= Zaawansowana inżynieria oprogramowania. Wykłady w serwisie edukacyjnym Ważniak |data dostępu= 2009-06-13}}
* {{cytuj stronę |url= http://wazniak.mimuw.edu.pl/index.php?title=Zpo-4-wyk-toc |tytuł= Zaawansowane programowanie obiektowe. Wykłady w serwisie edukacyjnym Ważniak |data dostępu= 2009-06-14}}
* {{cytuj stronę |url= http://msquaredtechnologies.com/m2rsm/docs/rsm_metrics_narration.htm |tytuł= Metrics Definitions – Resource Standard Metrics |język= pl |data dostępu= 2009-06-13 |archiwum= https://web.archive.org/web/20060623091745/http://msquaredtechnologies.com/m2rsm/docs/rsm_metrics_narration.htm |zarchiwizowano= 23 czerwca 2006 }}
* {{cytuj stronę |url= http://gromit.ict.pwr.wroc.pl/p_inf/ckjm/ |tytuł= ckjm – A Tool for Calculating Chidamber and Kemerer Java Metrics |język= en |data dostępu= 2009-11-04}}
* {{cytuj stronę |url= http://purl.org/MarianJureczko/MetricsRepo |tytuł=Metrics Repository – kolekcja obiektowych metryk oprogramowania |język= en |data dostępu= 2010-11-17}}

[[Kategoria:Analiza programów]]
[[Kategoria:Oprogramowanie]]
[[Kategoria:Zarządzanie jakością]]