FZN25代理_温州销量好的真空负荷开关价格怎么样

百度 类似的夸赞接踵而至，不久后，黄仲圭题赵孟頫《阴符经》楷书卷，称其笔力精到，不减右军这也是同代人首次把他与书圣相提并论，再次强调他在当代书坛的地位和价值。

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.

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

Zastosowanie

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, in?ynier oprogramowania Tom DeMarco uwa?a za?, ?e nie mo?na kontrolowa? tego, czego si? nie da zmierzy?. 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.

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.

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.

Charakterystycznym elementem jest paradygmat Cel – Pytanie – Metryka (GQM, 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. 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.

Podzia?

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

Metryki statyczne

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.

Metryki rozmiaru

Linie kodu

Przyk?adowy kod w Javie: wszystkich LOC jest 18, bez pustych linii 16, bez komentarzy 9, bez nawiasów 8

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.

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 metrykami Halsteada, 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:

• $\eta _{1}$ – liczba unikatowych operatorów
• $\eta _{2}$ – liczba unikatowych operandów
• $N_{1}$ – ca?kowita liczba wyst?pień operatorów
• $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:

• $\eta =\eta _{1}+\eta _{2}$ = s?ownictwo (vocabulary)
• $N=N_{1}+N_{2}$ = d?ugo?? (length)
• $V=N\cdot \log _{2}{\eta }$ = obj?to?? (volume).

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.

Inne metryki

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

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

Z?o?ono?? cyklomatyczna McCabe’a

Przyk?ad funkcji o niskim CC:
8 w?z?ów, 8 kraw?dzi,
CC = 8 – 8 + 2 = 2

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. 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,$

gdzie $e$ oznacza liczb? kraw?dzi, a $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,$

gdzie $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.

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:

$D={\tfrac {\eta _{1}}{2}}\cdot {}{\tfrac {N_{2}}{\eta _{2}}}$	trudno?? (difficulty), czyli podatno?? na b??dy, proporcjonalna do liczby unikatowych operatorów $(\eta _{1}),$ a tak?e do stosunku pomi?dzy wszystkimi $(N_{2})$ a unikatowymi operandami $(\eta _{2})$
$L={\tfrac {1}{D}}$	poziom programu (program level), im ni?szy, tym bardziej aplikacja jest podatna na b??dy
$E=V\cdot D$	wysi?ek (effort) potrzebny do zaimplementowania programu, proporcjonalny do trudno?ci oraz obj?to?ci $(V=N\cdot \log _{2}{\eta })$
$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={\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$ 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 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. 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).

WMC

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

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

gdzie $c_{i}$ jest pewn? miar? z?o?ono?ci metody $M_{i}$ ($M_{1},dots,$ $M_{n}$ to kolejne metody w klasie). Je?li za $c_{i}$ wstawimy sta?? 1, wynik b?dzie prostym zliczeniem wszystkich metod. W wariancie tej metryki za $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.

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:

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

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

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$ o 1, w przeciwnym razie nale?y zwi?kszy? $Q$ o 1. Warto?ci? LCOM b?dzie $\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$ = liczba metod w klasie

$a$ = liczba atrybutów w klasie

$mA(a)$ = liczba metod maj?cych dost?p do atrybutu $a$

$sum(mA)$ = suma warto?ci $mA$ po wszystkich atrybutach

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

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.

Metryki pakietów

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

Tree impurity

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$ oznaczymy liczb? kraw?dzi w grafie, a jako $n$ liczb? w?z?ów (pakietów), warto?? metryki wyniesie $2\cdot {\tfrac {e-n+1}{(n-1)\cdot (n-2)}}.$ Warto?? 0% oznacza, ?e graf jest pe?nym drzewem, za? 100% – klik?.

Metryki Roberta C. Martina

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

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 $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 $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?? $Ca,$ tym wi?cej odpowiedzialno?ci spoczywa na autorze zmian w kodzie danego komponentu. Wysokie $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 $Ce$ i $Ca$ pozwalaj? wyznaczy? niestabilno?? (instability, ozn. I) danej klasy lub pakietu:

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

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

Zobacz te?

• zarz?dzanie przez jako??

Bibliografia

• 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. Brak numerów stron w ksi??ce
• Cem Kaner, Walter P. Bond: Software Engineering Metrics: What Do They Measure and How Do We Know?. [dost?p 2025-08-14]. (ang.).
• Zaawansowana in?ynieria oprogramowania. Wyk?ady w serwisie edukacyjnym Wa?niak. [dost?p 2025-08-14].
• Zaawansowane programowanie obiektowe. Wyk?ady w serwisie edukacyjnym Wa?niak. [dost?p 2025-08-14].
• Metrics Definitions – Resource Standard Metrics. [dost?p 2025-08-14]. [zarchiwizowane z tego adresu (23 czerwca 2006)]. (pol.).
• ckjm – A Tool for Calculating Chidamber and Kemerer Java Metrics. [dost?p 2025-08-14]. (ang.).
• Metrics Repository – kolekcja obiektowych metryk oprogramowania. [dost?p 2025-08-14]. (ang.).