Kihagyás

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

kep

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

    kep

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

    kep

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

kep

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

Részletesebb lista

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 mutatóit a Sonar Qube és az SM plugin segítségével. Keressünk kiugró értékeket! Mi az esetleges magas komplexitás oka? Találtunk-e bad smelleket?


Utolsó frissítés: 2021-04-20 10:57:03