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

SZTE 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ális eloszlá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

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)

"Measuring programming progress by lines of code is like measuring aircraft building progress by weight." ~ Bill Gates.


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:

Mozilla

LOC lLOC

Function Method Classes Function Method Classes

Medián 13.4 6.0 36.5 13.4 5.5 27.1

Átlag 28.7 16.6 179.4 21.9 12.9 128.3


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

ősosztályok száma

összes osztály száma

leszármazott osztályok száma

ősosztályok száma


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

Bnum DIT NOP NOA NOC NOD

Bnum 1,000 0,016 0,154 0,067 0,000 0,000

DIT 1,000 0,233 0,783 0,000 0,000

NOP 1,000 0,448 0,000 0,000

NOA 1,000 0,000 0,000

NOC 1,000 0,988

Metrika Mozilla 1.6

DIT 1,52

NOP 0,87

NOA 1,93

NOC 0,88

NOD 1,95


30

Komplexitás-metrikák

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

"The central enemy of reliability is complexity" Geer et al.


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

CBO RFC WMC

CBO 1,000 0,696 0,561

RFC 1,000 0,709

WMC 1,000


39

Bad Smell 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]

“If it stinks, change it." ~ Grandma Beck.


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) Object Orientedness 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:

Metrika Pontosság (Precision)

Helyesség (Correctness)

Teljesség (Completeness)

WMC 65.38% 68.84% 55.24%

RFC 66.01% 71.89% 53.60%

CBO 69.77% 70.38% 69.12%

LCOM 64.69% 81.34% 43.68%

LOC 66.85% 72.98% 54.58%

Multi 69.61% 72.57% 65.24%

Modell Precision (pontosság)

Correctness (helyesség)

Completeness (teljesség)

Log. reg. 69.77% 70.38% 69.12%

Dönt. fa 69.77% 69.13% 67.02%

Neuronh.

69.46% 70.63% 65.13%


51

Referenciák [1] Park, Robert, E.: Software Size Measurement: A Framework for

Counting Source Statements. Software Engineering Institute, Pittsburg, SEI-92-TR-020, 220 pages, May 1992.

[2] Wolverton, R.W.: The Cost of Developing Large-Scale Software. IEEE Transactions on Computer, Volume C-23, No. 6, pp. 615-636, June 1974. Also in: Tutorial on Programming Productivity: Issues for the Eighties, IEEE Computer Society, Second Edition, 1986.

[3] L. M. Zap and B. Handerson-Sellers. Consistency consideration of object-oriented class libraries. Technical report, University of New South Wales, Sydney, Australia, 1993. research report no 93/3

[4] Rubey, R.J.; Hartwick, R.D.: Quantitative Measurement Program Quality. ACM, National Computer Conference pp. 671-677, 1968


52

Referenciák (folyt.) [5] Van Emden, M.H.: An Analysis of Complexity. Mathematisches

Zentrum, Amsterdam, 1971

[6] McCabe, T.: A Complexity Measure. IEEE Transactions of Software Engineering, Volume SE-2, No. 4, pp. 308-320, December 1976

[7] Halstead, M.H.: Elements of Software Science. New York, Elsevier North-Holland, 1977

[8] H. Bär, M. Bauer, O. Ciupke, S. Demeyer, S. Ducasse, M. Lanza, R. Marinescu, R. Nebbe, O. Nierstrasz, T. Richner, M. Rieger, C. Riva, A. M. Sassen, B. Schulz, P. Steyaert, S. Tichelaar, and J. Weisbrod. The FAMOOS Object-Oriented Reengineering Handbook. Technical report, Forschungszentrum Informatik, Karlsruhe, Software Composition Group, University of Berne, ESPRIT Program Project

21975, 1999.


53

Referenciák (folyt.) [9] Th. Panas, R. Lincke, J. Lundberg, , and W. Löwe.

A Qualitative Evaluation of a Software Development and Re-Engineering Project. In Proc. of the 29th NASA Software Engineering Workshop, April 2005.

[10] Tibor Gyimóthy, Rudolf Ferenc, István Siket: Empirical Validation of Object-Oriented Metrics on Open Source Software for Fault Prediction. IEEE Trans. Software Eng. 31(10): 897-910 (2005)

[11] Hakim Lounis, Lynda Ait-Mehedine: Machine-Learning Techniques for Software Product Quality Assessment. 102-109

[12] Martin Fowler and Kent Beck. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 2000.


54

Referenciák (folyt.) [13] William C. Wake. Refactoring Workbook.

Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2003.

Documents

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