Minőségmérés¶
A szoftver minősége összetett fogalom. Több tényező is meghatározza mit tekintünk jó minőségű szoftvernek Ezeket az ISO/IEC 25010 szabvány definiálja:
- Funkcionális megfelelőség
- Teljesítmény
- Hatékonyság
- Kompatibilitás
- Használhatóság
- Megbízhatóság
- Biztonság
- Karbantarthatóság
- Hordozhatóság
A minőségi mutatók aggregált mutatók, amelyek alacsonyabb szintű mutatókból tevődnek össze. Végső szinten a mutatók elemi szinten meghatározhatók. Köztük különösen fontosak azok, amelyek a szoftver forráskódjából határozhatók meg. Ezeket a mutatókat a statikus forráskód elemzés során mérjük.
Metrikák¶
Az olyan mutatókat, amelyek valamely termék, folyamat vagy erőforrás tulajdonságait számszerű, mérhető formában fejezik ki, metrikáknak nevezzük. A metrikák a folyamatok, termékek, erőforrások objektív értékelését teszik lehetővé.
Méret metrikák¶
A méret metrikák a rendszer elemeinek méretére vonatkozó számszerű mutatók, amelyeket az elemek leszámlálásával nyerünk ki
- Sorok száma:
- Lines Of Code (LOC): tényleges sorok száma
- Logical Lines Of Code (LLOC): nem üres, nem komment sorok száma
-
Példa:
- Az alábbi példában LOC = 4, LLOC = 2
-
Másik fontos csoport az egyes elemek száma, amely szintén leszámlálással kaphatók meg.
- Csomagok száma (NPKG - Number of Packages) (Java)
- Névterek száma (NNS - Number of Namespaces) (C++)
- Osztályok száma (NCL - Number of Classes)
- Struktúrák száma (NST - Number of Structures) (C)
- Interfészek száma (NI - Number of Interfaces) (Java)
- Metódusok száma (NM - Number of Methods)
- Attribútumok száma (NA - Number of Attributes)
- Utasítások száma (NOS - Number of Statements)
- Paraméterek száma (NUMPAR - Number of Parameters)
- Getter/setter (NG, NS)
Sorok száma¶
- Sok kritika éri (Bill Gates szerint: "Measuring programming progress by lines of code is like measuring aircraft building progress by weight.")
- Könnyű számolni
- Azonban nem egységes az értelmezése
- A sorok számának meghatározásában is eltérés lehet két tool között
- Nyelvekre nézve eltérő módon számolják
- A funkcionalitással sem lehet szoros kapcsolatot definiálni
- Egyéni teljesítmény meghatározására sem alkalmas
- GUI eszközök, programgenerátorok sok sort generálnak
- A többi méret metrika már több jelentést hordoz
Dokumentációs metrikák¶
- Komment metrikák
- A rendszer kommentezettségét mérik
- Többnyire arányszámok
- Nem méri a komment minőségét (pl. kikommentezett kód, TODO)
- Dokumentációs sorok száma (DLOC - Documentation Lines of Code)
- Komment sorok száma (CLOC - Comment Lines of Code)
- API dokumentáltság - fontos a minőség szempontjából
- PDA (Public Documented API)
- PUA (Public Undocumented API)
- Total API Documentation TAD: a dokumentált API aránya az összeshez
- A nyilvános API dokumentált legyen minden esetben!
A kommentezettséget mindig a kódsorokhoz kell viszonyítani, ennek alapján lehet becsléseket tenni
- Comment density CD : komment sorok aránya az összes sorhoz képest
- Figyelni kell arra, hogy a kommentek értelmesek legyenek
- Eljáráson belül használjunk beszédes változóneveket
- Az eljárások neve is tükrözze az eljárás célját
- Ne a kommentek magyarázzák a változók célját
- A kommentezés szerepét minimálisra kell csökkenteni, a kód legyen beszédes, érthető
- Egy komplexebb algoritmus leírása viszont indokolt lehet
- A publikus API-k viszont mindig legyenek dokumentáltak
Komplexitás metrikák¶
A komplexitással a kód bonyolultságára, annak megértésére vonatkozó nehézségekre, a karbantartáshoz, teszteléshez szükséges erőfeszítésekre lehet következtetni.
- McCabe komplexitás vagy ciklomatikus szám
- McCabe = E - N + P
- E a gráf éleinek száma
- N a csúcsok száma
- P összefüggő komponensek száma
- A csúcsok egy adott függvényben lévő utasítások
- Él akkor van két utasítás között, ha az egyik után a másik azonnal végrehajtódhat.
- McCabe = E - N + P
McCabe komplexitás
- Alternatív definíciók:
- McCabe = E - N + P
- McCabe = elágazási pontok száma + 1
- McCabe = zárt körök száma + 1
-
Közvetlen implikációk
- McCabe alulról becsüli a lehetséges futtatható útvonalakat a forráskódon keresztül
- McCabe felüről becsüli a minimálisan szükséges tesztesetek számát, ami a teljes lefedettséghez szükséges
Weighted Methods per Class
- Weighted Methods per Class komplexitás
- Chidamber and Kemerer (C&K)
- Értelmezhető
- Osztályokra
- Modulokra
- Fájlokra
- A WMC értéke a tartalmazott metódusok súlyozott összege, ahol a súlyok lehetnek:
- a metódusok McCabe komplexitásai
- LOC
- Utasítások száma (NS)
- 1, ebben az esetben súlyozatlan WMC, amely a metódusok száma (NM) lesz
További komplexitási metrikák
- Beágyazási szint (NL - Nesting Level): elágazások egymásba ágyazásának mértéke
- Nesting Level Else-If: itt az else if nem növeli a komplexitást
- Halstead metrikák: Maintainibility index becslése, amely tapasztalati adatokból származó komplex képleteket alkalmaz. Becsülhető például a fejlesztés ideje.
Öröklődés alapú metrikák¶
- Depth of Inheritance Tree (DIT): Az osztálytól a gyökérig vezető öröklődési útvonalak hosszának maximuma. Ha túl hosszú ez az út, akkor az áttekinthetőség romlik.
- Number of Parents (NOP)
- Number of Ancestors (NOA): Ha egy nyelv nem támogatja a többszörös öröklődést, akkor a DIT és NOA metrikák megegyezek
- Number of Children (NOC)
- Number of Descendant (NOD)
Csatolás metrikák¶
A hibaérzékenység egyik legjobb mutatója. Az osztály interakciók növekedésével a hibaelőfordulás valószínűsége is nő. A csatolás megvalósulhat metódushívásokon keresztül, illetőleg adatelérésen keresztül.
- Coupling Between Object classes (CBO): Egy osztály csatolva van egy másikhoz, ha használja annak attribútumát vagy metódusát vagy közvetlenül származik belőle
- Coupling Between Object classes Inverse (CBOI)
- Response For a Class (RFC): Azon metódusok számát adja meg, amelyeket egy osztály meg tud hívni
- Number of Incoming/Outgoing Invocations (NII, NOI)
Kohéziós metrikák¶
Azt mérik, hogy egy osztály metódusai és attribútumai mennyire szorosan függenek össze egymással. Ha egy osztály koherens, akkor csak egy funkcionalitást lát el. Ugyanakkor a funkcionalitásokkal összefüggő metódusok, adattagok kerüljenek is be egy osztályba.
- Van olyan adattag, amelyet mindketten használnak
- Egyik metódus hívja a másikat
- Lack of Cohesion On Methods (LCOM): Ha használnak közös adattagot, növeljük a P-t 1-gyel, egyébként pedig Q-t növeljük 1-gyel. LCOM = P – Q (P>Q): ha ez 0, akkor koherens.
- Lack of Cohesion On Methods 5 (LCOM5): ha a metódusokat egy gráf csúcsainak tekintjük és a metódusokat akkor kapcsoljuk össze éllel, amennyiben azok használnak közös adattagot, vagy egyik hívja a másikat, akkor az LCOM 5 ennek a gráfnak az összefüggő komponenseinek számát adja meg.
Klónok¶
A klónok ismétlődő kódrészek (copy paste használat). A probléma velük az, hogy nehezítik a karbantarthatóságot. Olyan esetben, ha egy másolt kódrészben hibát fedezünk fel, azt minden másolatban javítani kell, ami sok klón esetén könnyen elmaradhat. A klónok ugyanakkor nem minden esetben jelentenek problémát. Például kódgenerátorok, GUI-k esetében a kapcsolódó metrikák magasak, mégsem tekintjük problémának.
- Klón példányok (copy-paste részek) száma (Clone Instances - CI)
- Klón osztályok száma (Clone Classes - CCL)
- Klón lefedettség (Clone Coverage - CC): az adott elem klónlefedettségének aránya
- Klón komplexitás (Clone Complexity - CCO)
- Klón kora (Clone Age - CA) - mennyi elemzett verzió óta létezik az adott klón
Bad smell¶
Olyan programrészek, amelyek önmagukban nem hibásak, de azokká válhatnak az életciklus valamely szakaszában. Érdemes kivizsgálni őket.
"Ha a hűtőt kinyitva kellemetlen szagokat érzünk, az lehet attól is, hogy romlott étel van benne, de az is lehet, hogy a párunk egy különleges sajtot vásárolt előző nap a szupermarketben és az okozza a szagokat."
Példák:
- Data Class - adatosztály: csak adatmezőket és getter/setter párokat tartalmaz, nincs funkcionalitása
- Feature Envy - attribútum irigység: egy metódus gyakrabban használja más osztály adattagjait, mint a sajátját
- Large Class - nagy osztály, ezeket érdemes szétbontani
- Lazy Class - lusta osztály, túlságosan kevés szerepe van
- Long Method - hosszú eljárás, javasolt ezt is szétszedni
- Long Parameter List - hosszú paraméterlista a metódus megértését, használatát nehezíti, fontoljuk meg a paraméterek beágyazását egy összetettebb struktúrába
- Temporary Field - ideiglenes mező csak bizonyos esetekben tartalmaz értéket, más esetekben üres
A programrészek átalakítását, azok funkcionalitásának megtartása mellett refaktorálásnak nevezzük.
Minőség értékelése¶
A minőség értékeléséhez minden esetben az adott fejlesztési team, illetőleg az ügyfelek elvárásait kell figyelembe venni. Az egyes minőségi mutatókat a közvetlenül mérhető metrikákból építsük fel, aggregáljuk azokat. Az így felépített mutatókból áll a minőség modell. Az egyes minőségi modellek abban térnek el egymástól, hogy mely metrikákat és milyen súllyal vesszük figyelembe.
Az értékelés során a kapott mutatószámokat nem önmagukban kell vizsgálni, hanem baseline megoldásokhoz viszonyítjuk őket. Ezek olyan szoftverek, amelyek minőségét a team jónak minősítette. A metrikák értékelését tehát minden esetben ezekhez a modellekhez mérten kell elvégezni, az elfogadási küszöbszámokat (quality gate) beállítani.
A minőség értékelése tehát nem azonos a metrikák közlésével, de még a küszöbszámokkal együtt tekintve sem. Minden esetben értékelni kell a kapott eredményt.
Példa:
Ha az orvos vérvételre küld, a laborvizsgálat eredménye -> metrikák halmaza Az orvos értékelése és az orvosi javaslat -> minőségmérés
Feladat¶
- Vizsgáljuk meg projektünk minőségi mutatóit a SonarQube segítségével!
- Keressünk kiugró értékeket!
- Keressünk magas komplexitási metrikával rendelkező metódust! Mi lehet a magas komplexitás oka?
- Találtunk-e bad smelleket? Milyen lehetséges kockázatokra utalhatnak?