Java programok bonyolultságát mérő program, Eclipse plugin (Nagyprogram dokumentáció) Pataki Norbert, Sipos Ádám Témavezető: dr. Porkoláb Zoltán 2005. december 28.
Tartalomjegyzék 1. Bevezetés 3 1.1. Eclipse............................... 3 1.2. Metrikák és a szoftvertechnológia................ 3 1.3. Aspektus-orientált programozás................. 4 1.4. Az antlr.............................. 5 1.5. Tervminták............................ 5 2. AV-gráf 7 3. A metrika kibővítése az aspektus-orientált programozásra 9 3.1. Aspektusok............................ 9 3.2. Advice-ok............................. 9 3.3. Pointcut deklarációk....................... 10 3.4. Példák............................... 10 4. Felhasználói dokumentáció 12 4.1. Telepítés.............................. 12 4.2. A plugin helye az Eclipse környezetben............. 12 4.3. A kimenet............................. 13 5. Fejlesztői dokumentáció 15 5.1. A plugin felépítése........................ 15 5.2. Paraméterek kezelése, felhasználói felület............ 15 5.3. Szintaktikai elemzés........................ 16 5.4. AV-gráf építés........................... 16 5.5. Eredmények kimentése...................... 17 5.6. Osztályreferencia......................... 17 6. Tesztelési dokumentáció 19 6.1. Mérési eredmények........................ 20 1
7. Összefoglalás 22 2
1. fejezet Bevezetés Nagyprogramunk témája egy olyan Eclipse plugin kifejlesztése volt, amely Java illetve AspectJ programok bonyolultságát méri. Ehhez nézzük át az alapfogalmakat. 1.1. Eclipse Az Eclipse[1] egy ingyenes fejlesztői környezet, elsősorban Java fejlesztőknek, bár vannak lehetőségek C++, C# és egyéb nyelvek használatára is az IDEben. Az Eclipse-t Java-ban írták, nyílt forráskódú. Ugyanakkor lehetőséget ad arra is, hogy ún. plugin-okkal bővítsük a meglévő rendszert. A pluginok külön (Java) programok, amelyek beépíthetőek a meglévő rendszerbe, ezáltal kibővítve az IDE funkcionalitását. Maga az Eclipse is egy kis magtól eltekintve plugin-okból épül fel, és pluginokkal támogat olyan népszerű lehetőségeket, mint a refactoring, vagy az UML diagramok használata. Ez teszi népszerűvé a fejlesztőeszközt. 1.2. Metrikák és a szoftvertechnológia Már a korai időkben is felmerültek az alábbi kérdések a programokkal kapcsolatban: Milyen bonyolult a program? Mennyire könnyen illetve nehezen látható át a kód egy külső személy részéről? Milyen költsége lesz a tesztelésnek? 3
1.1. ábra. Az Eclipse IDE Mekkora költsége lesz a karbantartásnak és a továbbfejlesztésnek? Mérhető-e, hogy a programozó egy adott kódrészlet kapcsán helyesen döntött-e? A szoftvertechnológia ezekre a kérdésekre akart válaszolni, ezért különböző számítási modelleket dolgoztak ki. A különböző mérési eljárások által használt kiadott számadat a metrika. Például a legtriviálisabb mérték, a program sorainak a száma. Az idők folyamán programozási nyelvek és a paradigmák folyamatosan változtak, de az alapkérdések nem. Emiatt számos metrika alakult ki főleg az aktuális paradigmára korlátozva a számadat racionalitását. 1.3. Aspektus-orientált programozás A Java lett a melegágya egy új paradigma kifejlődésének. Az új paradigma az objektum-orientált paradigma felett valósult meg. Az új paradigmát 4
aspektus-orientált programozásnak nevezték el. Az aspektus-orientált programozás egy magasabb szintű absztrakciót vezet be az objektum-orientált programozáshoz képest. Megadja nekünk az alkalmazáslogikát keresztülvágó (crosscutting) síkok kiemelésének lehetőségét. Az AspectJ-re[2, 3] keresztelték a Java aspektus-orientált kiterjesztését. Mára számos nyelvet bővítettek ki az új paradigma használatára, pl. C++, Ruby, Python, PHP, stb.. Az új paradigma kapcsán, mindenkinek van szubjektív véleménye, hogy jobb-e, mint az objektum-orientált paradigma, sőt bizonyos feladattípusok kapcsán,,érezhetően jobb az új fajta megközelítés, ilyen például, amikor hibafelderítést kell végezni egy kódban (debug-golás), mert az eredeti kód módosítása nélkül tudjuk ezt elvégezni. Ugyanakkor nincs objektív információnk arról, hogy mikor érdemes az aspektus-orientáltságot kihasználni. Például, a [8] dolgozatban egy bonyolultabb alkalmazás kapcsán próbálta a szerző összehasonlítani a két paradigmát: a fejlesztés időtartama, a tesztelés időtartama, az ELOC metrika (Effective Lines of Code valódi kódsorok száma) illetve, informális eszközökkel: karbantarthatósági, újrafelhasználhatósági, modularitási jellemzőkkel. Az általánosan használt aspektus-orientált metrikák összefoglalása megtalálható a [9] cikkben. Ebben elég egyszerű metrikákat használnak, mint például a gyermekek száma (NOC Number of Children), ami összeszámolja az alosztályokat és az alaspektusokat, vagy egy aspektus keresztülvágásának a foka (CDA Crosscutting Degree of an Aspect), ami az egy aspektus által érintett modulok számát határozza meg. Hasonló metrikák leírása megtalálható a [10] honlapon is. Itt az adott metrikák implementációja is megtalálható. 1.4. Az antlr Az antlr[4] ANother Tool for Language Recognition egy parser generátor program, azaz egy nyelvtan szabályaiból elkészíti a lexikális és a szintaktikus elemzőt[5]. Sajnos, az AspectJ nyelvtana nem létezik megfelelő formátumban, ezért a Java nyelvtani szabályokat mi bővítettük ki, hogy aspektus-orientált programozást is lehessen elemezni. 1.5. Tervminták A tesztelés folyamán a tervmintáknak fontos szerepe volt, ezért ejtünk néhány szót ezekről is. 5
A tervminták (design patterns)[7] az objektum-orientált programozás e- gyik fontos eszköze. Bizonyos általános célú feladatokra nyújtanak általános érvényű megoldásokat, ezért használatuk mindennapos objektum-orientált környezetekben. Szokás osztályozni a tervmintákat, eszerint vannak létrehozási, szerkezeti, és viselkedési tervminták. A legismertebb tervminták: a singleton (egyke), az iterator, a feljegyzés, a figyelő. 6
2. fejezet AV-gráf Az AV-gráf mérték programok bonyolultságának mérésére alkalmas. Érdekessége, hogy mind a strukturális, mind az objektum orientált tulajdonságok alapján mér, nem pedig egy-egy kiragadott jellegzetességet használ fel. Ezt a paradigma-függetlenséget felhasználtuk arra, hogy aspektus-orientált programok bonyolultságát is meghatározhassuk. Az AV-gráf formális bevezetése megtalálható a [6] dolgozatban. Az AV-gráf bevezetését a programok adatkezelése indokolta: A Howatt és Baker-féle szám a vezérlési gráfok bonyolultságát igen jól kifejezi, azonban az adatok kezelését nem veszi figyelembe. Ellenben, az AV-gráf mindkét aspektus szerint határozza meg egy program bonyolultságát, és még ezen is túlmutató dolgokat is figyelembe vesz, mint például az adatáramlás iránya: a bonyolultság szempontjából nem mindegy, hogy írunk, olvasunk vagy írunk és módosítunk egy adatot. Az AV-gráfot a program szintaxisfájából kaphatjuk meg: az AV-gráf építésekor mindig el tudjuk dönteni, hogy utasítás csúccsal vagy adat csúccsal bővítjük a gráfot a vezérlési szerkezetnek megfelelően, a Java szemantikai értelmezése alapján az adatáramlás irányának megfelelően élet illetve éleket tudjuk a gráfba felvenni. Osztályok esetében, az osztály AV-gráfja az osztály függvényeinek AVgráfjainak az összessége. A gráfból lehet meghatározni a programok bonyolultságát, az AV-gráfot kell bejárni és összeadni a különböző részgráfokhoz tartozó bonyolultságokat. Az alábbi példa egy Java nyelven írt dátum osztály kódja és a hozzátartozó AV-gráfja: public class Date { private int year; 7
private int month; private int day; void set_next_month() { if (month == 12) { month = 1; ++year; } else ++month; } } void set_next_year() { if (year == -1) year = 1; else ++year; } 8
3. fejezet A metrika kibővítése az aspektus-orientált programozásra Mivel a [6] dolgozatban található metrika paradigma független, elsősorban ennek a bővítésével foglalkozunk. A paradigma függetlenség azt jelenti, hogy a metrika egyaránt használtható struktúrált, objektum-orientált, generikus vagy akár aspektus-orientált programokra is, esetleges bővítéssel. Vizsgáljuk meg, hogy a különböző AspectJ konstrukciók, hogyan befolyásolják a programok bonyolultságát. 3.1. Aspektusok Az aspektusok foglalják egységbe az advice-okat (lejjebb), vannak adatai, függvényei, tartalmazhat named pointcut-okat. Így ezek nagyon hasonlóak az osztályokhoz: vannak adatai (adattagjai) és advice-ai (ez tagfüggvény fogalmához áll közel). Így egy aspektus bonyolultsága: az adattagok, a tagfüggvények, az adviceok és a pointcutok bonyolultságának összege. 3.2. Advice-ok Az advice-ok fogalmazzák meg azt, hogy milyen kódot szőjjön hozzá a deklarációban szereplő függvényekhez a weaver. Az advice-ok bonyultsága az a deklaráció bonyolultságának és a törzse bonyolultságának a szorzata. 9
3.3. Pointcut deklarációk A pointcut deklarációk reguláris kifejezések, melyek meghatározzák, hogy az advice-ok törzsét hova kell beleszőni a programba. Lehetőség van ezeket névvel ellátni, ezesetben named pointcut-ról beszélünk. 3.4. Példák Az első példában egy int-et visszaadó, paraméter nélküli f függvény futását vizsgáljuk: public aspect LogAspect { before(): execution(int f()) { System.out.println("az f fuggveny elindul"); } } after(): execution(int f()) { System.out.println("az f fuggveny veget er"); } A második példa hasonló, de jóval többet bemutat a pointcut-ok lehetőségéről: a függvény neve f betűvel kell, hogy kezdődjön, tetszőleges objektumot adhat vissza, és akárhány paramétere és akármilyen típusú paramétere lehet: public aspect LogAspect { } before(): execution(* f*(..)) { System.out.println("az f* fuggveny elindul"); } A következő példában további lehetőségeket vizsgáljuk: itt a nem privát, int-et vagy void-ot visszaadó, olyan foo nevű függvény meghívását elemezzük, aminek akárhány paramétere lehet, és vagy Base osztálynak vagy abból származó osztálynak a tagfüggvénye: 10
public aspect LogAspect { } before(): call(!private (int void) Base+.foo(..)) { System.out.println("a foo fuggvenyt meghivtak"); } 11
4. fejezet Felhasználói dokumentáció 4.1. Telepítés Az Eclipse futtattásához szükség van, Java Virtuális gépre. Ez ma a legtöbb gépen megtalálható. 1. A CD-ről másoljuk át az eclipse könyvtárat a merevlemezre. Ebben a verzióban már benne van a plugin, ezért mást nem kell telepíteni. Az eclipse könyvtárban lévő weights.cfg file ne legyen írásvédett, ha módosítani kell a súlyokat. 2. Ha a környezet indítása után mégsem látszódna a plugin, akkor eclipse -clean paraméterrel futassuk az eclipse-t. 4.2. A plugin helye az Eclipse környezetben Sikeres telepítés után, a menürendszer kibővül egy új menüponttal: Metrika néven. A menünek két pontja van: Súlyok beállítása Mérés A Súlyok beállítása menüpontban a különböző nyelvi konstrukciók bonyolultságát tudjuk állítani, és elmenteni: A Mérés menüpontot kiválasztva, eldönthetjük, hogy egy file vagy könyvtár bonyolultságát kívánjuk-e mérni: Ezután kiválaszthatjuk a megfelelő inputot, majd a következő ablakon ellenőrizhető, hogy tényleg azt szeretnénk-e mérni, illetve beállítható, hogy az AV-gráfot is el szeretnénk-e menteni a dot file-ba. Ezután a mérés gombra 12
kattintva kiválasztható, hogy az eredmények milyen könyvtárba kerüljenek. A kiválasztás végeztével, a számítási folyamat elindul, és amikor véget ér, ezt jelezi. 4.3. A kimenet A program az eredményeket file-ba írja a megadott helyre: HTML és CSV típusú file-okba, illetve lehetőség van a függvények AV-gráfjának elmentésére is. A HTML kimenetet internet böngésző programokkal (pl. Internet Explorer, Mozilla Firefox, Opera, stb.) lehet megtekinteni, a CSV file-okat pedig 13
Microsoft Excel-lel. Az AV gráfokat, dot file-ba menti, aminek konvertálásához mellékelünk ingyenes programot. Ez képes jpg, ps, stb. formátumba konvertálni a gráfokat. 14
5. fejezet Fejlesztői dokumentáció A program két részből áll: az Eclipse pluginból az elemző programból 5.1. A plugin felépítése A plugin felépítése: A plugin, mint egyke osztály A pluginhoz kapcsolódó menüpontok, ablakok és kezelő osztályok Az elemző program felépítése: A program a következő fő részekre bomlik: Paraméterek kezelése, felhasználói felület Szintaktikai elemzés AV-gráf építés Eredmények kimentése 5.2. Paraméterek kezelése, felhasználói felület Amikor az Eclipse-hez plugint írunk, szigorú szabályokat kell betartani, hogy a plugint az Eclipse különböző verziói is használni tudják. Sajnos, maga az Eclipse API-ja is rendszeresen változik. 15
Mivel ezek a részek emiatt nagymértékben használják az Eclipse API-t, az öröklődési hierarchiák ismertetésétől eltekintünk. Maga a plugin egy egyke objektum, a menüpontok, az ablakok pedig szintén objektumok. Az események lekezelését (például gombnyomás) anonim osztályok temporális objektumai végzik. 5.3. Szintaktikai elemzés Az elemzést az ANTLR csomag végzi, mely egy olyan Java nyelvtanból készít elemzot, melyet a www.antlr.org-ról töltöttünk le. A nyelvtant ezután módosítottuk, hogy aspektus-orientált programokat is elfogadjon, majd implementáltuk a szintaxisfa-építést. Az ANTLR egy AST típusú csúcsokból álló fát hoz létre, melyből az elemzés során szerzett információkat lehet kinyerni függvényhívások segítségével. A program feltételezi, hogy az elemzett program szintaktikusan és szemantikusan is helyes (ellenkező esetben nincs értelme bonyolultságról beszélni). 5.4. AV-gráf építés A felépített szintaxisfán gráfkereséseket hajtunk végre. A program először részeire bontja az elemzett file-t: először osztályokra, majd azokat függvényekre szedi szét. Minden ily módon megtalált függvényhez készít egy AVgráfot, majd ezek súlyait összeadva képzi az osztály súlyát. Az AV-gráf a Node.java fileban implementált Node-okat, és annak leszármazottait tartalmazza. Minden utasításhoz létrehozunk egy InstructionNode-ot, majd erre egy irányított élt állítunk, és végére egy DataNode-ot kötünk 1. Az összes utasítás (értékadás, függvényhívás stb.) ilyen DataNode-ba kerül, majd erre egy másik típusú élt kötünk mely a paraméterek irányából mutat az utasításra. A paraméterek felől az utasításokba mutató élek nemcsak struktúrális tartalmazást jelenthetnek, hanem adatáramlást is. A bonyolultságba ez az írás-olvasás is beszámít. A program ezután bejárja a gráfot a struktúrális és adatfolyam élek mentén. A DataNode-ok és az élek bonyolultságát adja össze a program. 1 Több kitüntetett szerepű Instruction Node létezik, ilyen pl a PARAMETERS, mely a bejövő paramétereket köti, a RETURN, mely a függvény végét jelenti stb 16
5.5. Eredmények kimentése Az elemzett osztályok bonyolultságát a ComplexityData osztály példányai tárolják, ezeket csv illetve HTML file-okba tudja menteni. Az AV-gráfok a program paraméterezése szerint elmenthetők egy kimeneti dot file-ba. A struktúrális élek itt fekete éllel, az adatfolyam élek kékkel jelöltek. A Data- Node-ok háromszög alakúak, az InstructionNode-ok ellipszisek. 5.6. Osztályreferencia ComplexityData: egy függvény vagy osztály bonyolultságát tárolja DataNode: egy utasítás részműveleteit, azok paramétereit reprezentálja Edge: két Node közötti élt reprezentálja, lehet struktúrális (0 súlyú) illetve adatfolyam (1-2 súlyú) FileOrDirWidget: ez az osztály valósítja meg és kezeli azt az ablakot, ahol kiválasztjuk az input adat típusát, és magát az inputot 17
FlowGraph: az AV-gráf megvalósítása, képes megmérni a saját bonyolultságát FlowGraphBuilder: az ANTLR által elkészített szintaxisfában megtalált függvény definíciójából AV-gráfot készít InstructionNode: ezek az AV-gráf,,gerince, egy-egy utasítást jelentenek, ők,,tartják a gráfban a DataNode-okat JavaAST: az ANTLR AST osztályából származó osztály, mely a szintaxisfa egy csúcsát reprezentálja JavaLexer: lexikális elemző, az ANTLR készíti a nyelvtan alapján JavaMetric: ez az osztály kezdi el a szintaxisfa elemzését, megtalálja a különféle szerkezeti egységeket (osztály, interface stb) JavaRecognizer: szintaktikai elemző, az ANTLR készíti JavaTokenTypes: a tokeneket tároló file, az ANTLR készíti Main: főprogram MeasureOptions: a program paramétereit, beállításait tárolja MetrikaAction: a,,mérés menüpontot kezelő osztály MetrikaPluginPlugin: a plugint tároló egyke osztály MetrikaWeights: a,,súlyok beállítása menüpontot kezelő osztály MyJFace: a mérés elindítására szolgáló ablakot megvalósító és kezelő osztály Node: a Node típusok ősosztálya StartNode: egy függvény belépési pontját reprezentáló csúcs Statistics: az elemzett osztályok bonyolultságát tárolja TerminatingNode: egy függvény végét reprezentáló csúcs WeightsFace: a súlyok beállításakor látható ablakot megvalósító és kezelő osztály 18
6. fejezet Tesztelési dokumentáció A plugint csak Windows operációs rendszer alatt teszteltük. Bár a Java és az Eclipse is platformfüggetlen, mégis a plugin-nak előre meg kellett adni a futtattási paramétereket (pl. operációs rendszer illetve ablakozó felület). Emiatt a platform függetlenség kicsit sérül, bár szükség esetén viszonylag gyorsan át lehet állítani a plugin beállításait. A tesztelés elég komoly probléma egy ilyen szoftver kapcsán. Problémát jelent, hogy ha egy adott ponton rosszul számol a program, akkor a végeredmény nagyon eltorzulhat. Mivel hosszabb programoknak kézzel elég nehéz meghatározni a bonyolultságát, ezért arra törekedtünk, hogy a nyelvi eszközök minél szélesebb skáláját alkalmazva sok (kb. 15-20) rövid programnak határoztuk meg kézzel a bonyolultságát, és meggyőzödtünk arról, hogy a program is ezt adja eredményként. Az alábbi táblázat összefoglalja a legfontosabb teszteseteket, az,,építőkockákat, valamint az ezen kifejezésekre a program által kiszámított, majd általunk leellenőrzött bonyolultságot. Kifejezés Adatok nélkül Beágyazás nélkül Bonyolultság ++i; 1 4 4 if (true) ++i; 1 4 7 x=y; 1 5 5 if (true) x=y; 2 5 8 a=b+c; 2 9 9 if (true) a=b+c; 4 9 15 b+=c; 1 6 6 if (true) b+=c; 2 6 10 Ezen tesztesetek sikeres ellenőrzése után a programot a Tervminták javas és AOP-s megvalósításán is teszteltük, majd a kimenetként kapott AVgráfokat ellenőriztük. 19
6.1. Mérési eredmények A fenti kisebb programok után a [11] oldalon található tervminták Javas, majd AspectJava-s implementációján is teszteltük a programot. E megvalósítások egyenként is több osztályból, azok pedig több függvényből állnak, így egy-egy tervminta bonyolultsága ezen értékek összege. A tesztelés sikeres volt, a program ezekben az esetekben jól működött, és a mérés sikeres volt. Ezen eredményeket foglaltuk össze az alábbi táblázatban. Design Pattern neve Megvalósítás Adatok Beágyazás Bonyolultság nélkül nélkül adapter java 24 77 77 AOP 16 51 51 bridge java 82 231 235 AOP 82 233 237 builder java 100 191 219 AOP 91 181 201 decorator java 29 91 91 AOP 46 93 93 factorymethod java 42 113 113 AOP 50 129 129 flyweight java 90 277 299 AOP 90 270 286 interpreter java 148 549 567 AOP 148 549 567 memento java 33 83 99 AOP 65 127 186 observer java 120 356 374 AOP 108 305 305 prototype java 60 180 187 AOP 63 195 204 state java 77 247 259 AOP 60 167 179 strategy java 54 180 265 AOP 184 480 732 templatemethod java 51 158 158 AOP 51 158 158 visitor java 95 300 300 AOP 117 295 362 20
Összesen 23 tervminta található meg a honlapon, ebből a programunk a fenti 14-et tudja hibátlanul parse-olni és mérni. A program további javítása, valamint az eredmények elemzése (vagyis, hogy mely esetekben érdemes aspektus-orientált paradigmát alkalmazni, és mikor nem 1 ) további kutatómunkát igényel, és terveink között szerepel. 1 Más szóval: mi az oka, hogy pl a observer vagy state minták esetében sokkal egyszerubb a kód AOP környezetben mint natív java-ban, és miért fordított a helyzet pl a strategy mintánál 21
7. fejezet Összefoglalás Nagyprogramunk eredményei: Kidolgoztuk az AV metrika aspektus-orientált programok feletti kibővítését Megvalósítottuk az ezt mérő programot Elkészítettük az Eclipse-plugin-t A programot sikeresen teszteltük Ennek kapcsán sok mindennel megismerkedtünk: Aspektus-orientált programozással Szoftver metrikákkal Eclipse-szel antlr-rel Összetett kérdésekkel foglalkoztunk: Aspektus-orientált programozás hatékonyabb-e, mint az objektum-orientált? Mi alapján lehet ezt objektíven eldönteni? Mely metrikák függetlenek az aktuális paradigmáktól? Milyen feladatokon érdemes a tesztet elvégezni? 22
További fejlesztési lehetőségek vannak az AspectJ nyelvtanának bizonyos ritkábban használt elemeinek implementálásában, és a mérési eredmények elemzése során szerzett tapasztalatok alapján a metrika további finomhangolását is el lehet végezni. Fontos teendőnk még az eredmények mélyebbre ható vizsgálata. Még további lehetőség, hogy a Java új nyelvi eszközét, a generic-et[12, 13] is belevesszük a nyelvtanba illetve a mérésekbe, ezáltal a metrikát kibővítve a generikus paradigmára is. 23
Irodalomjegyzék [1] Eclipse Home, http://eclipse.org [2] The AspectJ project, http://eclipse.org/aspectj/ [3] Palo Alto Research Center, http://www.parc.com/research/projects/aspectj/default.html [4] ANTLR Parser Generator, http://antlr.org/ [5] Csörnyei Zoltán: Bevezetés a fordítóprogramok elméletébe I-II., ELTE Kiadó, 1996. [6] Porkoláb Zoltán: Programok Struktúrális Bonyolultságának Mérőszámai, 2003 [7] Sike Sándor: Programozási Technológia II, elektronikus jegyzet, 2004 http://people.inf.elte.hu/sike/pt2.ps [8] Magnus Mickelsson: Aspect-Oriented Programming Compared To Object-Oriented Programming When implementing A Distributed, Web-based Application, 2004, http://www.darkwolf.ws/aop/thesis/ [9] Mariano Ceccato, Paolo Tonella: Measuring the Effects of Software Aspectization, 2004, http://homepages.cwi.nl/~tourwe/ware/ceccato.pdf [10] aopmetrics: AOP Metrics, 2005, http://aopmetrics.tigris.org/metrics.html [11] Aspect-Oriented Design Pattern Implementations, 2004 http://www.cs.ubc.ca/~jan/aodps/ [12] Java Generics, http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html 24
[13] A Gentle Introduction to Generics in Java, http://bdn.borland.com/article/0,1410,32054,00.html 25