Forr

1
Forráskód metrikák szerepe a szoftver
minoségbiztosításban
Szegedi Tudományegyetem Szoftverfejlesztés Tanszék
2
You cant manage what you cant control, and you
cant control what you dont measure. (Tom
DeMarco)
3
Szoftvermérés

• Szoftvermérés
• termék vagy folyamat valamely jellemzojét
  numerikusan kifejezni (metrika)
• Három fo csoport létezik
• Folyamat és projekt metrikák
• Pl. egy hiba javításához szükséges átlagos ido
• 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 elso 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 elso 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 minoség
  mérésre is
• Defects/KLOC
• Elso regressziós minoségbecslo modell (Akiyama,
  1971)
• A hibák suruséget becsülte a LOC metrika
  segítségével

5
Történelmi áttekintés folyt.

• Új paradigmáknak megfelelo 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
• Eroforrás és költségigények megjósolása
• Modellek építése regressziós modellek, Bayes
  hálók
• Szoftvertermék minoségének megbecsülése
• A metrikák lehetnek
• Klasszikus / belso szoftver metrikák
• Pl. LOC, WMC, McCabe CC
• Aggregált / külso metrikák modellek
• Pl. karbantarthatóság, hibára való hajlamosság

7
Forráskód metrikák jelentosége

• Általában a rendszer egyetlen hiteles leírása a
  forráskód
• Minosé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 minosé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
Minoségbiztosítás

• Ipari környezetben a legelterjedtebb
  minoségbiztosítási eljárás a tesztelés
• Hátrányai
• Költséges
• A teszt-kód minosége kérdéses (lefedettség)
• Megelozésre nem alkalmas (csak utólagos
  kezelésre)
• Elonyei
• Funkcionális hibák feltárására is alkalmasak
• Az eredmények könnyebben kiértékelhetok
• A termékmetrikákon alapuló minosé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ú
minosé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értoi 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özo rendszerek metrikus értékeinek
  szisztematikus gyujté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 minosé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 egyenlotlensé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ínusé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éktol messze is viszonylag nagy
  valószínusé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 s 1.2
20
Statisztikai modellek folyt.

• Rendszerek összehasonlítása, rögzített metrika
  esetén
• Azonos eloszlás f(µ1, s1), f(µ2, s2)
• 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öklodé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 minosé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 legelso 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 Mozilla Mozilla Mozilla Mozilla Mozilla
LOC LOC LOC lLOC lLOC 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öklodés alapú metrikák

• A rendszerben található osztályok öröklodési
  kapcsolatait mérik
• Specialization és reUse metrikák
• A strukturáltságot és az újrafelhasználást méri
• Az elso öröklodés alapú metrikákat (DIT, NOC)
  Chidamber és Kemerer vezette be
• Osztály szintu metrikák

26
Öröklodés alapú metrikák (folyt.)
ososztályok száma
összes osztály száma

• 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 ososztá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

leszármazott osztályok száma
ososztályok száma
27
Öröklodés alapú metrikák (folyt.)
28
Öröklodés alapú metrikák (folyt.)

• DIT (Depth of Inheritance Tree)
• Az mondja meg, hogy hányadik öröklodési szinten
  található az adott osztály
• Ha túl mélyen található (DITgt5), akkor nehéz
  átlátni fejlesztés közben, hogy milyen tagjai
  vannak
• karbantarthatóságot, fejleszthetosé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ó
Metrika Mozilla 1.6
DIT 1,52
NOP 0,87
NOA 1,93
NOC 0,88
NOD 1,95

• 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
30
Komplexitás-metrikák

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

• Elso 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életbol származtatta (ciklomatikus szám)
• Függvények strukturális komplexitása
• Alulról becsüli a lehetséges futtatható
  útvonalakat
• Felurol 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 elofordulá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-minoség metrikák pontosabban közelíthetok
  Halstead metrikákkal
• McCabe és Halstead egymást kiegészítik
• WMC komplexitás (Chidamber and Kemerer (CK), 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, ellenkezo esetben többet
• Alacsony kohéziós érték rossz tervezést, magas
  komplexitásra utalhat (magasabb tesztelési
  költség)
• Metrikák
• LCOM1,2,3,4 (Lack Of Cohesion on Methods)
• http//doi.ieeecomputersociety.org/10.1109/WPC.200
  2.1021308

34
Kohéziós metrikák (folyt.)

• LCOM5
• Hitz Montazeri
• Az összefüggo komponensek számát adja meg
• Egy osztályban elvileg 1 összefüggo komponensnek
  kellene lennie
• Az összefüggo 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éroszá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 tesztelhetosé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 elorejelzo 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 lt2 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 -gt 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
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 minosé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
  egyszeru hibák javítása
• Komoly refactoringot igényel
• Néha részek újratervezése szükséges
• Metrikákkal felismerheto 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 mezo

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 minosé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ényezotol
  függ, és nagy mértékben szubjektív
• A kódolási minoség metrikák
• Könnyen megfoghatók
• Közvetlen hatásuk van a kód-minoségre
• Könnyen javíthatók
• Objektíven kiértékelhetok

45
Kódolási minosé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, eroforrásigények, szoftverminoség
  becslése
• Figyelembe kell venni, hogy
• A metrikák sokszor szervezet- és termékfüggok
• A metrikák az ido 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
• Elonye, 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é eso szám
• Ezt az értéket kerekítettük (kisebb vagy nagyobb
  mint 0.5), így kaptuk meg a megfelelo 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.