Metryki obiektowe i ich interpretacja

                                  Wojciech Podgórski

                            w...
1.   W jaki sposób powinno się ją stosować, czyli algorytmu obliczania lub
         wyznaczania wartości metryki dla poszc...
metryk. Niestety poprawne rozumienie takich związków wymaga od projektanta
ogromnego doświadczenia i niejednokrotnie związ...
DIT - Depth of Inheritance Tree (ang. głębokość drzewa dziedziczenia)
Określa maksymalna liczbę poziomów nadklas, z któryc...
Wartość oczekiwana: -


4 Metryki MOOD/MOOD2

Metryki MOOD zostały zaproponowane przez F. B. e Abreu w 1995 roku. W skład
...
MIF - Method Inheritance Factor (ang. współczynnik dziedziczenia metod)
MIF słuŜy do oceny stopnia wykorzystania mechanizm...
operacje wywołać. OHEF jest kryterium metryki MHF. Im wyŜsza wartość
efektywności tym lepiej został określony zasięg widoc...
Ce - Efferent coupling (ang. powiązania na zewnątrz)
Ce określa zaleŜność rozpatrywanego modułu od modułów zewnętrznych. W...
6 Problemy związane z stosowaniem metryk

Stosując metryki w procesie wytwarzania oprogramowania zawsze naleŜy pamiętać,
Ŝ...
7.1 Perspektywy polimet
                polimetryczne

Perspektywy polimetryczne zostały opracowane przez Michele Lanza i ...
efektywna w wykrywaniu nieprawidłowości i anomalii implementacyjnych. Plany
klas stanowią rozwinięcie i dopełnienie idei p...
dostępnych narzędzi nie znaleziono Ŝadnego, który implementował by metryki z
zestawu MOOD2.
Do pokrycia kodu metrykami z z...
7. Podgórski W.: Rola projektowania architektonicznego w inŜynierii oprogramowania
    zorientowanej na usługi. Praca semi...
Upcoming SlideShare
Loading in …5
×

Metryki obiektowe i ich interpretacja

4,255 views
4,103 views

Published on

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
4,255
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
54
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Metryki obiektowe i ich interpretacja

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

×