Metryki jakości

Dobra aplikacja powinna cechowa si :

zgodno ci z wymaganiami u ytkownika

niezawodno ci

efektywno ci

atwo ci konserwacji

ergonomiczno ci

Bardziej szczegó owe kryteria, które maj

bezpo rednie odzwierciedlenie w modelu i
projekcie:

spójno

przejrzysto

stopie powi za sk adowych

Spójno

“Najefektywniejszym systemem modularnym jest taki, w którym
suma powi za miedzy elementami nale

cymi do ró nych modu ów

jest minimalna. ... Spójno

ka dego modu u mo na rozumie

poprzez izolacj

– oraz

cis o

powi za

jego elementy

wewn trzne ze sob .”

Constantine i Yourdon w publikacji [3] okre laj

kilka rodzajów

spójno ci. Mimo i

rodzaje te zosta y stworzone z my l

o

projektowaniu strukturalnym to pewne rodzaje mo na odnie
równie do modelu obiektowego. Wyodr bnione zosta y nast puj ce
rodzaje spójno ci:

•przypadkowa – nie jest celowym dzia aniem, powstaje poprzez
podzia kodu programu na kilka plików, np. w celu u atwienia edycji,
co w przypadku jednego du ego zbioru danych by o by trudne lub
wr cz niemo liwe.

•logiczna – podzia

na modu y w obr bie których sk adowe

wykonuj

podobne funkcje np. graficzny interface u ytkownika,

obliczenia matematyczne

•czasowa – umieszczenie razem sk adowych które w czasie dzia ania
programu s

wykonywane w tym samym okresie czasu np.

uruchomienie lub zamkni cie programu

•proceduralna – sk adowe uruchamiane s zawsze w okre lonej
sekwencji

•komunikacyjna – sk adowe maj wspólne dane wej ciowe i wynik jest
wynikiem ich wspólnych dzia a

•sekwencyjna – sk adowe dzia aj podobnie jak dzia a
przekierowanie (pipe) w systemach UNIX'owych, gdzie dane
wyj ciowe jednej sk adowej s danymi wej ciowymi drugiej

•funkcjonalna – ka da sk adowa z modu u jest niezb dna do
wykonania pewnej funkcji programu

Przejrzysto

Dobry projekt powinien by

atwy do zrozumienia, czytelny, tym

samym

przejrzysty.

Wymaganie

to

jest

podyktowane

umiej tno ciami percepcji cz owieka. Komputer potrafi wykona
najbardziej zawi y ci g instrukcji. Dla cz owieka du o atwiej
post powa wed ug jasno okre lonego planu, ani eli oprócz trudu
w o onego

w

zrozumienie

problemu

radzenie

sobie

z

porz dkowaniem informacji.

“Matematyk-psycholog George

Miller ... opisa

ograniczenia

ludzkiego pojmowania. Wygl da na to e istota ludzka potrafi
radzi sobie, ledzi stan tylko oko o siedmiu obiektów, bytów, czy
koncepcji w danym czasie. W efekcie pami

wykorzystywana do

oblicze na wielu elementach jest ograniczona do 7 +/- 2 bytów.
Powy ej

tej

granicy,

b

dy

przetwarzania

rosn

nieproporcjonalnie.”

“Ograniczenia ludzkie w przetwarzaniu zagnie d onej informacji s
nawet wi ksze ni

te zwi zane z dzia aniami liniowymi,

sekwencyjnymi ... 'ludzki stos' mo e zosta przepe niony ju przy
dwóch lub trzech poziomach zag

bienia”

Na przejrzysto

wp ywaj nast puj ce czynniki:

•Sk adowe i ich zwi zki powinny odzwierciedla struktur problemu.
Powinny

by

jak

najbardziej

wiernym

odzwierciedleniem

rzeczywisto ci.

•Omówiona spójno

równie wp ywa na przejrzysto

, gdy spójne i

powi zane ze sob elementy s zrozumia e bez potrzeby odwo ywania
si do szerszego kontekstu.

•Z o ono

sk adowych na odpowiednim poziomie. W projektowaniu

obiektowym cz sto wykorzystuje si

dziedziczenie, które mo e

przyczyni si do przejrzysto ci, gdy na danym poziomie abstrakcji
dost pne s

tylko najbardziej potrzebne sk adowe. Jednak aby

dog

bnie zrozumie

sposób dzia ania niezb dne jest przejrzenie

ca ej hierarchii dziedziczenia.

•Nazwy składowych powinny być zrozumiałe, intuicyjne, odpowiadające
rzeczywistości

Stopie powi za sk adowych

Dobrze zaprojektowany model aplikacji powinien sk ada si z
mo liwie lu no powi zanych ze sob cz

ci. W takim przypadku

konieczno

zmiany jednej z nich w minimalnym stopniu wp ywa na

pozosta e elementy.

System ci le powi zany

System lu no powi zany

„Kluczowym pytaniem jest: Jak du o musimy wiedzie

o

jednym module aby by o mo liwe zrozumienie innego? Im
wi cej musimy wiedzie o module B aby zrozumie modu A,
tym mocniej zwi zany jest A z B. Fakt i musimy cokolwiek
wiedzie

o innym module jest dowodem a priori pewnego

stopnia po

czenia, nawet je li w danym momencie natura

zale no ci jest nie znana.”

Miary spójno ci (ang. Cohesion measures)

1. LCOM (ang. lack of cohension in methods)

Brak spójno ci metod – wyró niamy cztery jego rodzaje.
Miara jest liczb

par metod do siebie podobnych w klasie.

Podobie stwo metod jest okre lane na podstawie ich
argumentów, je li nie posiadaj wspólnych argumentów wtedy
dwie metody s

podobne do siebie w stopniu 0. Spójno

metod w klasie jest po

dana poniewa

promuje ona

enkapsulacj , a brak spójno ci oznacza e klasa powinna by
podzielona na dwie lub wi cej podklas.

1.1. LCOM1

Okre la liczb par metod w klasie których podobie stwo jest
równe 0. Miara im jest mniejsza tym klasa jest bardziej
spójna.

1.2. LCOM2

Okre la liczb par metoda w klasie, których podobie stwo jest równe
0 pomniejszon o liczb par których podobie stwo jest wi ksze od 0.
Uzupe niona miara jest bardziej proporcjonalna, gdy

bierze pod

uwag równie wielko

klasy. Je li wynik odejmowania jest mniejszy

od zera to warto

miary jest uznawana za 0. Im jest ta miara

mniejsza tym klasa jest bardziej spójna

.

1.3. LCOM3

Nale y rozwa y

graf nieskierowany, w którym wierzcho kami s

metody klasy. Mi dzy dwoma wierzcho kami istnieje kraw d

tylko

wtedy gdy metody mi dzy odpowiadaj ce metody maj przynajmniej
jeden wspólny atrybut. Miara jest liczb po

cze kraw dzi w grafie.

Im jest ta miara wi ksza tym klasa jest bardziej spójna.

1.4. LCOM4

LCOM4 jest pochodn miary LCOM3. Graf jest rozszerzony o
dodatkowe kraw dzie, które istniej

gdy jedna z

odpowiadaj cych wierzcho kom wywo uje drug

metod

z

swego wn trza. Im ta miara jest wi ksza tym klasa jest
bardziej spójna.

1.5. Co (LCOM4 modyfikacja)

E – ilo

kraw dzi w grafie

V – ilo

wierzcho ków w grafie

Im ta miara jest wi ksza tym klasa jest bardziej spójna.

LCOM5

Rozwa my zbiór metod { M

j

} (i=1,...,m) których atrybuty

nale

do zbioru { A

i

} (j=1,...,a). Niech µ(A

i

) b dzie ilo ci

metod których atrybutem jest A

i

. Wtedy miar

LCOM5

okre lamy wzorem:

Im jest ta miara wi ksza tym klasa jest bardziej spójna.

Coh (LCOM5 modyfikacja)

Rozwa my zbiór metod { M

j

} (i=1,...,m) których atrybuty nale

do zbioru { A

i

} (j=1,...,a). Niech µ(A

i

) b dzie ilo ci

metod

których atrybutem jest A

i

. Wtedy miar

LCOM5 okre lamy

wzorem:

Im jest ta miara wi ksza tym klasa jest bardziej spójna.

TCC (ang. tight class cohesion)

cis a spójno

klasy jest miar , której warto

jest okre lana jak

procent par publicznych metod klasy, które s

powi zane

bezpo rednio. Powi zanie metod okre la si

jako zwi zek mi dzy

metodami odwo uj cymi si do tego samego pola klasy po rednio lub
bezpo rednio. Po rednie odwo anie istnieje gdy metoda m wywo uje
w swoim ciele metod m', która bezpo rednio odwo uje si do danego
pola klasy.
Im jest ta miara wi ksza tym klasa jest bardziej spójna.

LCC (ang. loose class cohesion)

Luźna spójność klasy jest miarą, której wartość jest określana jak
procent par publicznych metod klasy, które są powiązane bezpośrednio
lub pośrednio. Powiązanie metod określa się jako związek między
metodami odwołującymi się do tego samego pola klasy pośrednio lub
bezpośrednio. Pośrednie odwołanie istnieje gdy metoda m wywołuje w
swoim ciele metodę m', która bezpośrednio odwołuje się do danego pola
klasy.
Im jest ta miara większa tym klasa jest bardziej spójna.

Miary przejrzysto ci

2. Miary dziedziczenia

Jest to zbiór miar zwi zanych z drzewem dziedziczenia.
Dziedziczenie

pozwala

na

zmniejszenie

wielko ci

kodu

ród owego oraz organizacj

logiczna kodu, jednak zbyt

rozbudowane mo e utrudnia

analiz

i zrozumienie budowy

komponentów. Brak zrozumienia mo e prowadzi

do b

dnego

rozszerzenia ju istniej cych klas lub z e u ycie.

2.1. DIT (ang. depth of inheritance tree)

G

boko

drzewa dziedziczenia jest to d ugo

najd u szej

cie ki dziedziczenia od klasy do korzenia w hierarchii.

Jej wielko

nie powinna przekracza

pewnej p ynnej granicy,

przyjmuje si j na poziomie 4-6 poziomów.

2.2. AID (ang. average inheritance depth of a class)

rednia g

boko

dziedziczenia klasy jest równa zero, gdy

klasa nie posiada przodków, dla innych przypadków warto
jest redni warto ci przodków powi kszon o jeden.

Jej wielko

nie powinna przekracza pewnej p ynnej granicy,

przyjmuje si j na poziomie 4-6 poziomów.

2.3. CLD (ang. class-to-leaf depth)

Głębokość od klasy do liścia jest maksymalną ilością poziomów w
hierarchii które są poniżej danej klasy.

Jej wielkość nie powinna przekraczać pewnej płynnej granicy,
przyjmuje się ją na poziomie 4-6 poziomów.

2.4. NOC (ang. number of children)

Ilo

dzieci okre la ilo

klas dziedzicz cych bezpo rednio z danej

klasy.
Zbyt du a liczba potomków mog a by sugerowa dodanie dodatkowego
poziomu dziedziczenia, gdy by mo e da si znale

cechy wspólne dla

cz

ci klas pochodnych i stworzy dla nich now super klas , b d c

dzieckiem badanej.

2.5. NOP (ang. number of parents)

Ilo

rodziców z których klasa dziedziczy bezpo rednio.

Ta miara powinna by mo liwie najmniejsza, zbyt du a liczba rodziców
mog aby oznacza i dana klasa posiada zbyt wiele funkcji w systemie i
nale a oby rozwa y

stworzenie dwóch lub wi cej odr bnych klas.

Górna granica kszta tuje si

na poziomie 2-4 rodziców, najnowsze

j zyki programowania id

o krok dalej umo liwiaj c dziedziczenie

jednokrotne, takie podej cie eliminuje dodatkowe problemy jak na
przyk ad sytuacj w której dwaj rodzice maj implementacj metody o
tej samej nazwie i liczbie i typie atrybutów. Aby jednak by o mo liwe
odwo ywanie si

do klasy poprzez konkretny “typ” j zyki te

pozostawiaj

mo liwo

implementacji wielu interfejsów. Przyk adem

takiego j zyka mo e by j zyk Java.

2.6. NOD (ang. number of descendents)

Liczba potomków po rednich i bezpo rednich.

Okre la wielko

ga

zi drzewa dziedziczenia.

2.7. NOA (ang. number of ancestors)

Ilo

przodków okre la ilo

klas w drzewie dziedziczenia, które s

nad klas .

2.8. NMO (ang. number of methods overriden)

Ilo

metod nadpisanych okre la ile metod implementowanych przez

rodzica zostaje ponownie zaimplementowanych w klasie pochodnej.

2.9. NMI (ang. number of methods inherited)

Ilo

metod odziedziczonych po przodkach, które nie zosta y

nadpisane w danej klasie.

2.10. NMA (ang. number of methods added)

Ilość

metod dodanych w danej klasie, które nie zostały

odziedziczone lub nadpisane w danej klasie.

2.11. SIX (ang. specialization index)

Indeks specjalizacji jest kompozytow miara obliczan przy u yciu
innych miar:

SIX = NMO * DIT / (NMO+NMA+NMI)

3. Miary wielko ci

Miary tego typu pozwalaj na oszacowanie wielko ci kodu. Jak ju
by o wspominane poprzednio ludzki umys

ma ograniczone

mo liwo ci poznawcze, wi c czy wi kszy jest projekt tym trudniej
jest zrozumie , obj

go przez co mo e by generowanych wiele

b

dów wynikaj cych z przeoczenia lub nie zrozumienia dzia ania

modu ów oprogramowania. Równie

wielko

klas decyduje o

stopniu zrozumienia przez programist , projektanta.

3.1. NM (ang. number of methods)

Ilo

metod, które posiada klasa, bez rozró nienia pomi dzy

odziedziczonymi a dodanymi, czy nadpisanymi.

3.2. NAI (ang. number of attributes)

Ilo

pól klasy, dodanych nie odziedziczonych po przodkach,

w

czone s równie typy proste takie jak int, string.

3.3. Nmpub (ang. number of public methods)

Ilo

publicznych metod zaimplementowanych w danej klasie.

3.4. NMNpub (ang. number of non-public methods)

Ilo

nie publicznych metod (prywatnych lub chronionych)

zaimplementowanych w danej klasie.

3.5. NumPara (ang. number of parameters)

Ilo

parametrów wszystkich metod zaimplementowanych w danej

klasie.

3.6. SLOC (ang. source lines of code)

Ilo

linii kodu ród owego, miara ta okre la ilo

fizycznych

aktywnych linii kodu, które nie s puste lub zakomentowane. Zliczanie
SLOC jest jednym z najprostszych i naj atwiejszych podej

do

mierzenia z o ono ci. Jest to równie

najbardziej krytykowana

metoda. Im wy sza miara SLOC tym modu

jest trudniejszy do

zrozumienia i utrzymania.

3.7. CP (ang. comment percentage)

Procent komentarzy okre lony jest jako stosunek linii komentarzy do
kodu i niepustych linii kodu programu. Przyjmuje si

e warto

powy ej 20% jest wystarczaj ca dla j zyka C i Fortran. Wysoka
warto

wskazuje na

atwiejszy w utrzymaniu kod, gdy

jest

atwiejszy do zrozumienia poprzez dokumentacje w komentarzach.

4. Miary stopnia powiązań składowych

Miary stopnia powiązań stanowią przeciwieństwo miar spójności.
Powiązań między modułami, klasami powinno być możliwie jak najmniej co
ułatwi zrozumienie projektu oraz w przypadku ewentualnych zmian ich
zasięg może być lokalny w przypadku małej ilości powiązań.

4.1. CBO (ang. coupling between object classes)

Zależność między klasami zgodnie z definicją zachodzi wtedy gdy
metoda jednej klasy używa metod lub pól drugiej klasy. Wartością tej
miary jest liczba klas powiązanych z dana klasa. Zalicza się również
klasy powiązane poprzez dziedziczenie.

Im mniejszą wartość przyjmuje miara tym lepiej. Wysoka wartość może
oznaczać słabą enkapsulację klasy i może stanowić problem przy
ponownym użyciu kodu.

4.2. CBO' (ang. coupling between object classes)

CBO' jest zdefiniowana w ten sam sposób co CBO z wyłączeniem
zależności związanych z dziedziczeniem.

Im mniejszą wartość przyjmuje miara tym lepiej.

4.3. RFC (ang. response set for a class)

Zbiór odpowiedzi dla klasy jest definiowany jako liczba metod które
mog

by

potencjalnie wywo ane po rednio i bezpo rednio w

odpowiedzi klasy na otrzymanie komunikat z zewn trz. Bezpo rednie
wykonanie metody zachodzi wtedy gdy jest wywo ywania z cia a innej
metody nale

cej do danej klasy.

Im mniejsz warto

przyjmuje miara tym lepiej.

4.4. RFC' (ang. response set for a class)

RFC' definiowane jest tak jak RFC tylko z wy

czeniem metod

wywo ywanych po rednio,

Im mniejsz warto

przyjmuje miara tym lepiej.

4.5. MPC (ang. message passing coupling)

Zale no

przekazania wiadomo ci jest ilo ci

wywo a

metod w

danej klasie.

Im mniejsz warto

przyjmuje miara tym lepiej

.

4.6. DAC (ang. data abstraction coupling)

Zale no

abstrakcyjnych danych jest ilo ci pól klasy, których typy

s innymi klasami projektu.

Im mniejsz warto

przyjmuje miara tym lepiej.

4.7. DAC' (ang. data abstraction coupling)

Zale no

abstrakcyjnych danych jest ilo ci pól klasy, których typy

s innymi unikatowymi klasami projektu.

Im mniejsz warto

przyjmuje miara tym lepiej.