1 / 54

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

Forráskód metrikák szerepe a szoftver minőségbiztosításban. Szegedi Tudományegyetem Szoftverfejlesztés Tanszék. “You can’t manage what you can’t control, and you can’t control what you don’t measure.” (Tom DeMarco). Szoftvermérés. Szoftvermérés

giulio
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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:

More Related