Forráskód metrikák szerepe a szoftver minőségbiztosításban

1. Forráskód metrikák szerepe a szoftver minőségbiztosításban Szegedi Tudományegyetem Szoftverfejlesztés Tanszék

2. “You can’t manage what you can’t control, and you can’t control what you don’t measure.”(Tom DeMarco)

3. Szoftvermérés • Szoftvermérés • termék vagy folyamat valamely jellemzőjét numerikusan kifejezni (metrika) • Három fő csoport létezik • Folyamat és projekt metrikák • Pl. egy hiba javításához szükséges átlagos idő • Specifikációs metrikák • Pl. funkció-pontok • Termék metrikák (forráskódon alapuló metrikák) • Pl. sorok száma, ciklomatikus komplexitás, osztály metódusainak száma

4. Történelmi áttekintés • Az első metrikákról szóló könyv 1976-ban jelent meg • Gilb T, Software Metrics, Chartwell-Bratt, 1976. • Már a 60-as évek közepén használták a LOC (Lines of Code) metrikát • LOC/pm a programozók teljesítményének mérésére • Az első modellek a LOC-ot használták teljesítmény, költség mérésére • Effort = f(LOC) • A 60-as évek végén a LOC-ot használták minőség mérésre is • Defects/KLOC • Első regressziós minőségbecslő modell (Akiyama, 1971) • A hibák sűrűséget becsülte a LOC metrika segítségével

5. Történelmi áttekintés folyt. • Új paradigmáknak megfelelő metrikák megjelenése • pl. objektum orientált, aspektus orientált, generatív • Aggregált metrikák (attributes) megjelenése, validálása • Maintainability index, Functionality, Reliability, stb. • ISO/IEC 9126 • Metrikákon alapuló modellek építése és validálása • Hibára való hajlamosság • Predikciós modellek • Monitorozó rendszerek fejlesztése

6. Metrikák szerepe, célja • A menedzsment döntéshozatalának alátámasztása a szoftver teljes életciklusa során • Kockázat elemzés és csökkentés • Erőforrás és költségigények megjósolása • Modellek építése – regressziós modellek, Bayes hálók • Szoftvertermék minőségének megbecsülése • A metrikák lehetnek • Klasszikus / belső szoftver metrikák • Pl. LOC, WMC, McCabe CC • Aggregált / külső metrikák – modellek • Pl. karbantarthatóság, hibára való hajlamosság

7. Forráskód metrikák jelentősége • Általában a rendszer egyetlen hiteles leírása a forráskód • Minőségirányítási rendszer bevezetésekor már létezik a szoftver egy verziója • A folyamat metrikákra nem támaszkodhatunk • A fejlesztés további része a Karbantartás és Továbbfejlesztés (termékmenedzsment) – a költségek 65%-át teszi ki • Meg kell határozni annak kiindulási minőségét • Hogy a költségeket becsülni tudjuk, és • Képesek legyünk javítani a folyamatunkon • Folyamat és termék mérése együtt kell hogy történjen, egymást kiegészítve

8. Minőségbiztosítás • Ipari környezetben a legelterjedtebb minőségbiztosítási eljárás a tesztelés • Hátrányai: • Költséges • A teszt-kód minősége kérdéses (lefedettség) • Megelőzésre nem alkalmas (csak utólagos kezelésre) • Előnyei: • Funkcionális hibák feltárására is alkalmasak • Az eredmények „könnyebben” kiértékelhetők • A termékmetrikákon alapuló minőségbiztosítás pontosan a tesztelés hátrányait küszöböli ki • A tesztelés nem váltható ki vele teljes mértékben

9. Forráskód metrikák helye a forráskód-alapú minőségbiztosítási módszertan rendszer-architektúrájában

10. Metrikák kiértékelése • A forráskód metrikák önmagukban nem nyújtanak semmit • A kiértékelésükhöz (Diagnózis) szükséges: • Baseline értékek ismerete (nehéz: sok tapasztalat szükséges, domain-specifikus) • Szakértői tudás (metrikák jelentésének pontos ismerete) • Tendenciák vizsgálata • Metrikus értékek változásának nyomon követése

11. Baseline értékek • Különböző rendszerek metrikus értékeinek szisztematikus gyűjtése • Univerzum • Nagy számok törvénye: sok rendszeren egy adott metrikára számított átlag „átlagos”. • Jelenleg több nagy ipari, és open-source rendszerre vonatkozó metrikus értékekkel rendelkezünk • Méretük: 100 KLOC – 30 MLOC

12. Baseline értékek folyt.

13. Baseline értékek folyt. • Rendszer minőségének kiértékeléséhez nem elég tudni hogy hány esetben van baseline túllépés, hanem a túllépés mértékét is figyelembe kell venni • Bonus-Malus modell • Statisztikai modellek építése

14. Bonus-Malus modell Baseline index: -5,4 Baseline index: -6,02

15. Bonus-Malus modell folyt. • A modell hátrányai: • Diszkrét beosztás – a beosztás megválasztása önkényes • Nem szimmetrikus • Háromszög egyenlőtlenség nem teljesül • Helyette precíz matematikai formalizmus szükséges

16. Statisztikai modellek • Bonus-Malus általánosítása • Egy adott rendszer elemei rögzített metrika esetén bizonyos valószínűséggel vesznek fel egyes értékeket. • Szoftvermetrikákkal kapcsolatos eloszlások: • Normális-eloszlás • Lognormális eloszlás • Pareto eloszlás Fat-tail eloszlások

17. Statisztikai modellek folyt.

18. Statisztikai modellek folyt. • Fat-tail eloszlások • A várható értéktől messze is viszonylag nagy valószínűséggel vesz fel értéket • Sok metrika Lognormáliseloszlást követ • Például LOC, WMC, McCabe • Bizonyos „gráf-metrikák” is ilyenek (NI, NII)

19. Statisztikai modellek folyt. Q-Q Plot μ = 0.7 σ = 1.2

20. Statisztikai modellek folyt. • Rendszerekösszehasonlítása, rögzített metrika esetén: • Azonos eloszlás: f(μ1, σ1), f(μ2, σ2) • Paraméterbecslések (maximum likelihood) • Norma definiálása • Származtatott távolság

21. Forráskód metrikák csoportosítása • A termékmetrikák lehetnek: • Nyelv-független (LOC) • Nyelv-specifikus (OOP paradigma) • A típusuk szerint lehetnek: • Méret metrikák (LOC, NA, NM) • Öröklődés metrikák (DIT) • Komplexitás metrikák (McCabe, WMC) • Kohéziós metrikák (LCOM) • Csatolás metrikák (CBO) • Bad Smell (és Copy-Paste) metrikák (CC) • Kódolási minőség metrikák (szabálysértések)

22. Méret metrikák "Measuring programming progress by lines of code is like measuring aircraft building progress by weight." ~ Bill Gates. • Méret metrikák – a rendszer (elemek) mérete • Legismertebbek: • LOC (Lines Of Code) – sorok száma • lLOC (Logical Lines Of Code) – nem üres, nem komment sorok száma • NCL/NST/NUN (Number of CLasses/ STructures/ UNions) • NNS (Number of Namespaces) • NA/NM (Number of Attributes, Number of Methods) • NF (Number of Functions)

23. Méret metrikák (folyt.) • LOC, lLOC • A legelső ismert/használt metrika [1] • Teljesítmény, komplexitás mérésére is használták [2] (assembly) • 1983 Basili és Hutchens javasolta, hogy az összes többi metrikát a LOC metrikához viszonyítsák (normalizálás) • LOC metrikára több mint 10.000 cikkben van hivatkozás • Hátrányok: • Alacsony korreláció a funkcionalitással • Egyéni teljesítménymérésre nem alkalmas • Programozási nyelvek közötti különbségek • A funkciópontok számát nem befolyásolja • Fejlett GUI-eszközök figyelmen kívül hagyása

24. Méret metrikák (folyt.) Statisztikai értékek:

25. Öröklődés alapú metrikák • A rendszerben található osztályok öröklődési kapcsolatait mérik • Specialization és reUse metrikák • A strukturáltságot és az újrafelhasználást méri • Az első öröklődés alapú metrikákat (DIT, NOC) Chidamber és Kemerer vezette be • Osztály szintű metrikák

26. Öröklődés alapú metrikák(folyt.) • ReUse index (U) = • Az osztályok újrafelhasználási arányát méri • Mozilla esetében ez az érték 0.38 • Specialization index (S) = • Azt mutatja meg, hogy az ősosztályok mennyire sikeresen emelték ki a rendszer absztrakt tulajdonságait • A magas érték nagyfokú újrafelhasználást mutat a leszármazott osztályoknál • A Mozillánál ez az érték 2.22

27. Öröklődés alapú metrikák(folyt.)

28. Öröklődés alapú metrikák(folyt.) • DIT (Depth of Inheritance Tree) • Az mondja meg, hogy hányadik öröklődési szinten található az adott osztály • Ha túl mélyen található (DIT>5), akkor nehéz átlátni fejlesztés közben, hogy milyen tagjai vannak • karbantarthatóságot, fejleszthetőséget csökkenti • Korábban vizsgáltuk a DIT és NOC illetve a hibák közti összefüggéseket • A DIT esetében „gyenge” kapcsolatot találtunk • A NOC esetében nem találtunk kapcsolatot

29. Korreláció • A metrikák és a hibaszámok közti korrelációs kapcsolat a Mozilla esetében

30. Komplexitás-metrikák "The central enemy of reliability is complexity" Geer et al. • Első komplexitás metrikákkal foglalkozó cikk 1968-ban jelent meg (Rubey [4]) • A 70-es évek közepén jelentek meg a McCabe [6] és a Halstead [7] metrikák • Thomas McCabe a komplexitás fogalmát a gráf-elméletből származtatta (ciklomatikus szám) • Függvények strukturális komplexitása • Alulról becsüli a lehetséges futtatható útvonalakat • Felűről becsüli a minimálisan szükséges teszt-esetek számát • McCabe által javasolt baseline érték: 10, speciális esetben 15

31. Komplexitás-metrikák (folyt.)

32. Komplexitás-metrikák (folyt.) • Halstead komplexitás • Lexikális, textuális komplexitás • Operandusok, operátorok előfordulási számának felhasználásával • Azokon a részeken, ahol nagyobb mértékben szerepelnek számítási logikai megvalósítások a kód-minőség metrikák pontosabban közelíthetők Halstead metrikákkal • McCabe és Halstead egymást kiegészítik • WMC komplexitás (Chidamber and Kemerer (C&K), H. Bär [8], Th. Panas [9]) • A tartalmazott metódusok súlyozott összege (súlyok: McCabe, LOC, 1, stb.)

33. Kohéziós metrikák • Azt mérik, hogy egy osztály metódusai mennyire szorosan függnek össze egymással • Egy koherens osztály csak 1 funkcionalitást lát el, ellenkező esetben többet • Alacsony kohéziós érték rossz tervezést, magas komplexitásra utalhat (magasabb tesztelési költség) • Metrikák: • LCOM{1,2,3,4} (Lack Of Cohesion on Methods) • http://doi.ieeecomputersociety.org/10.1109/WPC.2002.1021308

34. Kohéziós metrikák (folyt.) • LCOM5 • Hitz & Montazeri • Az összefüggő komponensek számát adja meg • Egy osztályban elvileg 1 összefüggő komponensnek kellene lennie • Az összefüggő komponensek száma közelíti az osztály által megvalósított funkcionalitások számát • Mozilla: 6.18

35. Kohéziós metrikák (folyt.) – LCOM5

36. Csatolás metrikák • Mérőszám, hogy ez egyes osztályok mennyire kapcsolódnak másokhoz • Metódushívásokon keresztül • Adateléréseken keresztül • Magas csatolás érték • Alacsony egységbezárás • Újrahasználhatóság gátlása • Hibaszám növekedése (az osztály-interakciók következménye) • Alacsony tesztelhetőség • Változásra való érzékenység • Legismertebbek: • CBO (Coupling Between Object classes) • RFC (Response For a Class) • COF (Coupling Factor)

37. Csatolás metrikák (folyt.) • CBO(Coupling Between Object classes) • Chidamber & Kemerer • Azon osztályok száma, amiket az adott osztály használ • „Ortogonális” a WMC metrikára • Hiba előrejelző modellek az irodalomból • Tibor Gyimóthy, Rudolf Ferenc, István Siket [10] • Hakim Lounis [11] • Döntési fa alapú modellekben a CBO a legjobb • Pl. Mozilla: CBO <=2 osztályok száma: 2286 (47 %) • Lefedett hibák száma: 132 (5%)

38. Csatolás metrikák (folyt.) • RFC (Response For a Class) • Chidamber & Kemerer • Azon metódusok számát adja meg, amelyeket egy osztály meg tud hívni válaszul egy kapott üzenetre • RFC ~ WMC + CBO • Ha az objektum-orientáltság csökken, akkor • a korreláció az RFC, WMC, CBO metrikák között csökken • RFC -> WMC + CBO • Másik jelentés: • Ha egy osztály túl sok választ tud adni egy üzenetre, akkor az nehezebbé teszi a tesztelését • Az átlag a Mozilla 1.6 esetében 19,4

39. Bad Smell “If it stinks, change it." ~ Grandma Beck. • A szoftverfejlesztés során a keletkezhetnek nem kívánatos, kevésbé hatékony részek • Ezekre több jel is utalhat • Ezeket rossz szagú (Bad Smell) helyeknek nevezzük • Nem metrikus érték, hanem a kód azon pontjainak a megjelölésére szolgál, amelyek valamilyen szempontból problematikusak • A Bad Smell-ek számának változása sokat mond a rendszer minőségének alakulásáról (ez is metrika) • Nem mindig jelentenek hibát, csak felhívják a figyelmet olyan pontokra, amelyeket érdemes kivizsgálni • Fowler [12], Wake [13]

40. Bad Smell (folyt.) • A tényleges Bad Smell javítás nehezebb mint az „egyszerű hibák” javítása • Komoly refactoringot igényel • Néha részek újratervezése szükséges • Metrikákkal felismerhető Bad Smell-ek • Data Class - Adat Osztály • Feature Envy - Attribútum Irigység • Large Class - Nagy Osztály • Lazy Class - Lusta Osztály • Long Method - Hosszú eljárás • Long Parameter List - Hosszú Paraméterlista • Temporary Field – Ideiglenes mező

41. Bad Smell (folyt.) - Mozilla

42. Klón metrikák • Copy-paste használat mérése • Karbantarthatóság • Legfontosabb kapcsolódó metrikák: • CCL – Clone Classes • CI – Clone Instances • CC – Clone Coverage • Paraméterek: • Klónok minimális hossza (LOC, NS, stb.) • Egyezés típusa (Teljes, Részleges) • Scope (Függvény-, Osztály-, global-scope)

43. Klón metrikák (folyt.)

44. Kódolási minőség metrikák • Kódolási szabálysértések • Scott Meyers: Effective C++ • A korábbi metrikák nehézkesen használhatók egyéni teljesítmény mérésére • A metrikus értékek kiértékelése az implikációk megbecsülése nehéz, sok befolyásoló tényezőtől függ, és nagy mértékben szubjektív • A kódolási minőség metrikák • Könnyen megfoghatók • Közvetlen hatásuk van a kód-minőségre • „Könnyen” javíthatók • Objektíven kiértékelhetők

45. Kódolási minőség metrikák (folyt.) • Hátrányuk: • Csak lokális problémák felfedezésére alkalmas • Az összetettebbek nehezen számíthatók (CFG, PTA, …) – a kód részleges szemantikus értelmezése szükséges • Kódolási szabálysértések osztályozása: • Bugs and Dangerous Constructs (BDC) • Memory Handling Problems (MHP) • ObjectOrientedness Problems (OOP) • Complexity Problems (CP) • Readability and Consistency problems (RCP) • Code Layout Problems (CLP) • A csoportosításban átfedések vannak

46. Aggregált metrikák • Aggregált szoftver metrikák az ISO/IEC 9126 szabvány szerint • Funkcionalitás • Megbízhatóság • Használhatóság • Hatékonyság • Karbantarthatóság • Hordozhatóság

47. Aggregált metr. (folyt.)

48. Modellek • Cél: költségek, erőforrásigények, szoftverminőség becslése • Figyelembe kell venni, hogy • A metrikák sokszor szervezet- és termékfüggők • A metrikák az idő függvényében változnak • A tapasztalati tudás integrálása fontos • Módszerek • Több metrika együttes vizsgálata • Pl. statisztikai és gépi tanulási módszerek alkalmazása • Sok projekt esettanulmányának vizsgálata

49. Modellek (folyt.) - Eszközök • Lineáris regresszió • Lineáris kapcsolatot feltételez az ismert és ismeretlen mennyiségek között (metrikák vs. bugok száma) • A valóságban a kapcsolat nem lineáris • Előnye, hogy a hibaszámokat is becsli • Logisztikus regresszió • Nem a hibaszámot, hanem csak a kategóriát (hibás-e) becsülhetjük vele (0 v. 1) • A kimenet egy 0 és 1 közé eső szám • Ezt az értéket kerekítettük (kisebb vagy nagyobb mint 0.5), így kaptuk meg a megfelelő kategóriát

50. Eredmények (folyt.) • Logisztikus regresszió • CBO: