2013. március 3., vasárnap

Sonar - A metrikák értelmezése 2.

A múltheti bejegyzésem folytatásaként most a komplexitás és a csomagok közötti függőségek jellemzőiről fogok írni!

Complexity

A komplexitást a metódusokban található feltételes és vezérlési szerkezetek száma határozza meg, azaz az értéke a for, do, while, break, continue, if, else, case, default, return, catch, throw, throws, finally, &&, ||, ?, :, ^, &, | szerkezetekkel eggyel fog nőni. A widget jobb oldalán egy oszlop diagramon látható a projekt összes metódusának, ill. fájljának a komplexitás szerinti eloszlása. A komplexitásnál az alacsonyabb értékek tekinthetők jónak, mivel ezek kevesebb metódusonkénti feltételes és vezérlési szerkezetet, így karbantarthatóbb kódot jelentenek. A widget jobb oldali oszlop diagramja akkor tekinthető ideálisnak amikor baloldalra súlyozódik, mivel ilyenkor az egyszerűbb metódusok vannak többségbe. Általánosan elmondható, hogy a metódusonkénti 2.5 érték jónak tekinthető, 7 felett pedig már érdemes refaktorálni, azaz átszervezni a metódus kódját!


Package Tangle Index

Habár a Java projekteket jar-okba, csomagokba, fájlokba, osztályokba és metódusokba szervezzük ettől még nem feltétlenül lesz az alkalmazásunk moduláris! A tervezésnél figyelnünk kell arra, hogy az osztályok lazán csatoltak és erősen összetartóak legyenek (LCOM4, RFC) valamint arra is, hogy a csomagok között ne alakuljanak ki függőségi körök (Package Tangle Index). A package tangle index tehát a projekt csomagjai között kialakult függőségeket mutatja, aminek a feloldásához a Dependency Structure Matrix (DSM) használatát ajánlja a Sonar. Két java package között akkor alakul ki körbefüggés, amikor az egyik csomag valamelyik java osztályának egy másik csomag valamely java osztályára van referenciája és ez fordítva is teljesül! A csomagok közötti függőségeket azért érdemes elkerülni, mert ezek a csomagok egy szoros egységet fognak alkotni - ezzel csökkentve a modularitást - így azok majd nem választhatók el a későbbiekben egymástól! 

A következőkben a TinyJEE project, Doxia :: Include - Macro-ján keresztül fogom ismertetni a csomagok közötti függőségek felkutatását és azok feloldását. Az alábbi ábrán látható Sonar widget szerint 2-nél több körbefüggés van a projektben és ezek megszüntetéséhez 1 helyen kell a csomagok közötti függőségeket szétvágni, ami úgy tűnik hogy nem lesz nehéz feladat mivel csak 1 fájlt fog érinteni a módosítás!


Ha rákattintunk a widget-en található valamelyik linkre, akkor az alábbi ábrán látható függőségi struktúra mátrixhoz (DSM) jutunk, ami segítségünkre lesz a függőségek feloldásához. A táblázat sorainak első celláiban az egyes java csomagok nevei találhatóak, az oszlop nevek pedig ehhez hasonlóan alakulnak csak helyhiány miatt nincsenek feltüntetve. A gyanúsított függőségeket a piros négyzetek jelölik, így a munkát is itt kell kezdeni.

 

Ha kétszer rákattintunk az  org.tinyjee.maven.dim sorban található piros négyzet 1-es számára, akkor a táblázat alatt megjelenik, hogy a org.tinyjee.maven.dim.utils csomagból egy osztályának (AbstractAliasHandler) referenciája van a org.tinyjee.maven.dim csomag RequestParameterTransformer osztályára.


Látható, hogy a kattintás során a piros négyzet háttere lilára vált és a táblázatban kijelölődik egy másik cella is lila színűre. Ha ebben a cellában található 3-as számra kétszer rákattintunk, akkor az alábbi ábra szerint a táblázat alatt megjelennek a konkrét függőségek listája. Az org.tinyjee.maven.dim csomagban vannak olyan osztályok, amelyek a org.tinyjee.maven.dim.utils csomag osztályaira tartanak referenciát, ami az előző ábrát tekintve pont fordított, azaz megállapítható, hogy az említett 2 csomag között körbefüggés áll fent amit érdemes megszüntetni a modularitás fenntartása érdekében!


Látható, hogy a DSM segítségével gyorsan felderíhetők a csomagok közötti függőségek. A Sonar további eszközöket is biztosít a forráskód minőségének feljavításához amelyekről hamarosan olvashatsz a blogon.

2 megjegyzés:

  1. Juj. Legyszives, tedd meg azt a szivesseget, hogy sokkal ovatosabban forditasz. Bar az angol valoban dependency cycle-nek hivja, ez nem igazan ciklus, inkabb fuggosegi kor vagy korbefugges. Tudod, mint ahogy a bicycle sem kettos ciklus, hanem kerekpar. :-)

    Elnezest, de az ilyen nyilvanvalo felreforditas annyira szurja a szememet...

    VálaszTörlés
    Válaszok
    1. Köszönöm az fordításbeli észrevételt és a kedves példát is!

      Törlés