Nagyméretű forráskódtárak inkrementális statikus analízise

Nagyméretű forráskódtárakinkrementális statikus analízise

konzulensek: Szárnyas GáborDr. Ráth István

Budapesti Műszaki és Gazdaságtudományi EgyetemMéréstechnika és Információs Rendszerek Tanszék

Hibatűrő Rendszerek Kutatócsoport

Stein Dániel, BSc

Folytonos integráció (FI)

Continuous Integration (CI) – Több fejlesztő együttműködése

– Integrációs problémák megelőzése

– Például

– Jenkins

– Hudson

– Travis CI

2

Verziókezelés

Fordítás

Fejlesztés

Egység- és integrációs teszt

Statikus analízis

– Nincs szükség a program fordítására és futtatására

– Alaki és strukturális jellegű szabályellenőrzést végez

– FI mellett vagy részeként alkalmazandó

– Kódmintaillesztést használunk

3

Verziókezelés

Fordítás

Fejlesztés

Egység- és integrációs teszt

Kódanalízis

– A kódanalízis erőforrás- és időigényes folyamat

– Lassú, nem alkalmazható FI-szerű ütemezéssel

Megoldandó probléma

4

egységteszt

kódanalízis

☼ ☆☾☆



– Átmeneti megoldás: tömbösítés


5

egységteszt

kódanalízis

☼ ☆☾☆

egységteszt

kódanalízis



– Átmeneti megoldás: tömbösítés

Minél hamarabb,

minél gyorsabban

eredményt kell adni.


6

egységteszt

kódanalízis

☼ ☆☾☆

egységteszt

kódanalízis

A bemutatott megoldás

–Inkrementális elvet alkalmazunk

A számított eredményt csak a későbbi

változás hatásával frissítjük.

–Projekt helyett fájl szintű feldolgozás

–Későbbi skálázhatóságot,

eloszthatóságot figyelembe véve terveztük

7

kódanalizátor

Δ2.-1.1.

Architektúra áttekintés

8

Munkaterület Függőségigráf

Absztraktszintaxis gráf

Jólformáltságiszabályok

Lekérdezés futtatása Adatbázis

Main.java | ++----Dependency.jar | +++++-FIterator.java | ----Cparser.java | ++

Automatikusjólformáltsági

szabály kiértékelés

Kézi futtatásés kiértékelés

Automatikustöbbszörözés és elosztás

. jamoppdiscoverer ChangeProcessor.java CommandParser.java FileIterator.java iterators DepCollector.java FileDiscoverer.java InitIterator.java Main.java whitepages ConnectionMgr.java DependencyMgr.java pojo Dependency.jar

.jar

.java

Kiértékelési jelentés

<!><?>

<.>

JaMoPP

Verzió-kezelő


9











.jar

.java


<!><?>

<.>

JaMoPP

Verzió-kezelő


10











.jar

.java


<!><?>

<.>

JaMoPP

Verzió-kezelő


11











.jar

.java


<!><?>

<.>

JaMoPP

Verzió-kezelő

Munkaterület



Verzió-kezelő

Architektúra verziókövetés

–Verziókezelőre épül

– Követi a fájlok változását, illetve az elágazó fejlesztési ágakat

– Lekérdezhető a fájlok pillanatnyi állapota és a verziók közötti módosítások listája

–Munkaterület-központú

– Projekt forrása

– Függőségek forrása(amennyiben elérhető)

12

Függőségigráf


.jar

.java

JaMoPP

Architektúra átalakítás

–Függőségi gráf

– Segédkomponens a későbbi feldolgozáshoz

– A gráf élei a Java függőségeknek megfeleltethetők

–Absztrakt szintaxis gráf

– A projektet modellé, majd azt gráffá alakítjuk

13

Függőségigráf


.jar

.java

JaMoPP







14

Minden fájlra leírók gyűjtése és tárolása:package, szükséges fordítási egységek, stb.

Minden további alrendszer számára elérhető információval szolgál

Függőségigráf


.jar

.java

JaMoPP







15

Függőségigráf


.jar

.java

JaMoPP







16

A forráskód struktúrájának gráf reprezentációja

Nem tartalmaz minden információt

Részgráfokból állítjuk elő a teljes gráfot


Lekérdezés futtatása AdatbázisAutomatikus

jólformáltságiszabály kiértékelés




<!><?>

<.>

Architektúra modellfeldolgozás

Felhasználói ki-és bemenet

17

Felhasználói bemenet kiértékelése és kimenet

előállítása

Adattárolás és lekérdezés-végrehajtás







<!><?>

<.>



18


előállítása


Gráfadatbázis

Technológiai választásunk: 4store

Elasztikusan skálázódik







<!><?>

<.>



19


előállítása








<!><?>

<.>



20


előállítása


Gráfmintaként (SPARQL nyelven) megfogalmazott kódminták

Lekérdezések végrehajtása(akár inkrementálisan)

Jelentés előállítása (vagy frissítése)







<!><?>

<.>



21


előállítása





ASG-n értelmezett minta

Informális specifikáció







<!><?>

<.>



22


előállítása











<!><?>

<.>



23


előállítása


Visszajelzés a felhasználónak

Felsorolja a szabályokat megszegő kódrészleteket










<!><?>

<.>



24


előállítása





Példa forráskód

public static String toMonth(int month) {switch (month) {

case 1: return "January";case 2: return "February";case 3: return "March";case 4: return "April";case 5: return "May";case 6: return "June";case 7: return "July";case 8: return "August";case 9: return "September";case 10: return "October";case 11: return "November";case 12: return "December";default: return "Invalid month";

}}

25Bemeneti forráskód (részlet) Kódmodell (részlet)

Példa forráskód



}}


switch:Switch

...january

:NormalSwitchCase

december

:NormalSwitchCase

#//Switch/cases

#//Switch/variablemonth

:IdentifierReference

Példa gráfminta

30

sw: Switch

sc: DefaultSwitchCase

cases

Default ág nélküli switch-eket kereső gráfminta

Absztrakt szintaxis gráf (részlet) Gráfminta-illeszkedési találatok:

switch:Switch

...january

:NormalSwitchCase

december

:NormalSwitchCase

#//Switch/cases



Példa gráfminta

31

sw: Switch


cases


Absztrakt szintaxis gráf (részlet) Gráfminta-illeszkedési találatok: switch :Switch

switch:Switch

...january

:NormalSwitchCase

december

:NormalSwitchCase

default

:DefaultSwitchCase

#//Switch/cases



Példa gráfminta

32

sw: Switch


cases


Absztrakt szintaxis gráf (részlet) Gráfminta-illeszkedési találatok: switch :Switch

switch:Switch

...january

:NormalSwitchCase

december

:NormalSwitchCase

default

:DefaultSwitchCase

#//Switch/cases



Példa gráfminta

33

sw: Switch


cases


Absztrakt szintaxis gráf (részlet) Gráfminta-illeszkedési találatok:

Mérési kiértékelés

–Kiértékelő teljesítménymérés

– Az egyes fázisok egymáshoz viszonyított futási idejét vizsgáljuk

– Különböző méretű, nyílt forráskódú projekteken végezzük el az analízist

– Alap (teljes projekt) és módosítás inkrementális feldolgozását mérjük

–Mérési környezet: publikus felhő, elosztott adatbázissal

34

Forrás projekt Kódsorok száma Fájlok száma

Physhun 4 227 53

Java DjVu 41 497 69

Xalan 338 316 907

92.18

425.79

2 378.25

1

10

100

1000

Physhun

4 227 / 35

Java DjVu

41 497 / 69

Xalan

338 316 / 907

Teljes

feld

olg

ozá

si id

ő [

s]

(FG

, A

SG

, m

enté

s, l

ekér

dez

és)

Projektek

forrás sorok száma / fájlok száma

Mérési eredmények

35

92.18

425.79

2 378.25

1

10

100

1000

Physhun

4 227 / 35

Java DjVu

41 497 / 69

Xalan

338 316 / 907

Teljes

feld

olg

ozá

si id

ő [

s]

(FG

, A

SG

, m

enté

s, l

ekér

dez

és)

Projektek

forrás sorok száma / fájlok száma


36

1 555

345 951

27 535

213

966

23 354 27 870

201

100

1000

10000

100000

1000000

10000000

Függőségi gráf

építése

Absztrakt szintaxisgráf

összeállítása

Modell

tárolása

Lekérdezések

futtatása

Fázi

s fu

tási

id

eje

[m

s]

Első, teljes futtatás

Módosítás inkrementális feldolgozásaNagyságrendi

különbség

Mérési eredmények inkrementális

37

1 555

345 951

27 535

213

966

23 354 27 870

201

100

1000

10000

100000

1000000

10000000

Függőségi gráf

építése

Absztrakt szintaxisgráf

összeállítása

Modell

tárolása

Lekérdezések

futtatása

Fázi

s fu

tási

id

eje

[m

s]

Első, teljes futtatás

Módosítás inkrementális feldolgozásaNagyságrendi

különbség

Mérési eredmények inkrementális

38

-85%

4.09 8.42

4.35

2.14

28.36

52.19

375.04

1 10 100 1000

FindBugs

PMD

Checkstyle

Columbus

inkr. ISAaC

ISAaC

Teljes futási idő [s]

Fordítás

Analízis

Mérési eredmények összehasonlítva

39

Összefoglalás

– Szabványos formátumok és cserélhető komponensek

– Java forráskód átalakítása RDF gráffá, akár elosztott megközelítéssel

– Az elkészített gráf inkrementális frissítése is megoldott

– Moduláris, bővíthető és skálázható

inkrementális statikus analízis

keretrendszert készítettem

– Java forrást RDF gráffá alakító

segédeszközt implementáltam

– Benchmark funkciókkal bővítettem

a keretrendszert és méréseket

végeztem

40

Újszerű megközelítés az inkrementális statikus analízishez:

Továbbfejlesztési lehetőségek

– Inkrementális analízis INCQUERY-D használatával

– Feldolgozás granularitásának javítása minden fázisban

– Keretrendszer elosztottá tétele

41

Átalakítás és perzisztálás

Munkaterület beállítása

Függőségek felderítése

Lekérdezések futtatása

Szerver 1

Szerver 2

Szerver 3

Szerver 4

Szerver 1

Szerver 2

Szerver 3

Szerver 4

Szerver 1

Szerver 2

Szerver 3

Szerver 4

Sz. 1

Sz. 2

Sz. 3

Sz. 4

Á P

Á P

Á P

Á P

L1 L2

L3

L4 L5

L6

Összefoglalás

– Szabványos formátumok és cserélhető komponensek

– Java forráskód átalakítása RDF gráffá, akár elosztott megközelítéssel

– Az elkészített gráf inkrementális frissítése is megoldott

A dolgozat eredményei a MONDO EU-FP7 kutatási projekthez kapcsolódnak, annak egyik demonstrátorát képezik.

42

Újszerű megközelítés az inkrementális statikus analízishez:

Bírálói kérdések

A dolgozat említi, hogy a JaMoPP Java 5 támogatása az újabb verziójú Java kódok elemzését nem teszi lehetővé. Van lehetőség ennek a komponensnek a lecserélésére? Milyen alternatív megoldásokat vizsgált meg?

– Réteges az architektúra, a komponens cserélhető, de jobb jelölt nincs jelenleg nincs.

– A metamodell bővíthető, de sok munka lenne. Az újabb verziójú kódot is feldolgozza, de nem hibamentesen.

– Alternatívák:

– MoDisco (projekt szintű feldolgozás, de átalakítható)

– Columbus (zárt forráskódú, viszont JaMoPP-hoz jobban hasonlít)43

Többször említésre kerül az adatbázis alapú tárolás által lehetővé tett elosztott ellenőrzés lehetősége. Milyen tényezőket érdemes egy ilyen megoldásnak a teljesítménybeli és pénzügyi hatékonyságágának megtervezéséhez figyelembe venni?

– Használt tárterület

– A forráskód XMI modellje ~2-5×.

– Az RDF sorosítás ~4-10×.

– Az adatbázis viszont tömörítheti a sokszor ismétlődő szövegrészleteket (pl. URI, attribútum).

– Elérési sebesség

– Több adatbázis szerver gyorsíthatja az olvasást, keresést (de ez nem lassú).

– Az írási és szinkronizációs sebesség viszont csökkenhet.


44


A már létező ellenőrző eszközökhöz nagy számú szabály áll rendelkezésre. Milyen csoportokra lehetne osztani ezeket a szabályokat az esetleges migráció megtervezésekor technológia és bonyolultság szerint? Esetleg minden szabály átírása egyértelmű? Mekkora feladatot jelentene pl. a PMD-hez rendelkezésre álló szabályok átírása?

– A mintaalapú megközelítés (PMD) könnyebben átírható. A metamodellekkülönbsége miatt kézzel kell feldolgozni, de JDT AST-szerű mindkét metamodell.

– Az IncQuery-D használatával bonyolultabb lekérdezések (pl. count) megvalósítható, nem csak mintaillesztés.

– Csoportra példa:sorrend alapú minta (nem az utolsó case a default), ami RDF esetén nehezebben megoldható. 45


A forráskódban fellelhető hibákon kívül nagy projekteknél komoly problémát jelent, ha egy adott library-nek több verziója is jelen van futás közben. Ezt a build rendszerek, pl. Maven, Gradle, explicit kizárásokkal, felülírásokkal és további “trükkökkel” próbálják orvosolni. Volna lehetőség ilyen jellegű problémák kimutatására a keretrendszer kiterjesztésével? Milyen módon lehetne ezt implementálni?

– A keretrendszer nem pont erre lett kialakítva, a classpath kezdetleges.

– Library függésével, függőségi és hatásanalízissel Csikós Donát foglalkozott, az ő munkáját lehetne követni.

– Több library kezelése megoldható a keretrendszer paraméterezésével és a projektek verziókezelt mentésével. Ehhez átdolgozott mentési stratégia szükséges.

46


Hogyan hasonlítható össze a készített ISAaC rendszer egy olyan rendszerrel hatékonyság szempontjából, amely egy meglévő statikus kódanalizátort futtat a megváltozott fájlokon (és ezek függőségi lezártján)?

– FindBugs és PMD analizátorok integrálása a benchmark rendszerbe

– Találatok ellenőrzése

– Vagy nem használjuk fel a változások listáját (teljes futtatás)

– Vagy a modosítás függőségi lezártján futtatjuk az ellenőrzést

– Befolyásolhatja a mérés hűségét, hogy a lezárt alatt ugyanazt érti-e a másik szoftver fejlesztője, mint a mi megoldásunkban

47


Jelenlegi granularitás a fájl, mint egység, ami jóval nagyobb lehet, mint a "changeset". Mi a praktikusan elérhető legkisebb granularitás?

– JaMoPP esetén a feldolgozás fájlonként történik, ennél kisebb egység nem vizsgálható.

– Azonban hatásanalízis használatával a szükséges feldolgozandó fájlok száma csökkenthető.

– Modellösszehasonlító használatával AST node szintig levihető a granularitás.

48


Kb. mennyi, az inkrementális mivoltából fakadó extra tárhelyet használ a rendszer a példában szereplő projektek esetén?

– Az inkrementális feldolgozáshoz csak a módosítás előtti szerializált részgráfot tároljuk el.

– Egy fájlhoz tehát legfeljebb a gráf formátumban tárolt modell méretének kétszerese szükséges.

– A szövegesen tárolt gráf tömöríthető.

49


Mi szükséges a Java mellett más nyelvek támogatásához?

– A JaMoPP-hoz hasonló parser, ami képes a Java forrásból programmatikusan feldolgozható példánymodellt készíteni.

– Szükséges, hogy a fájlok közti hivatkozás részenként sorosíthatólegyen, egyértelmű, hierarchikus azonosítókkal.

projects://ISAaC/src/Teszt.java#//@statements.0/@...

50

1.49 1.95

11.42

81.8

395.6

2 110.8

8.73

28.01

255.79

1

10

100

1000

Physhun

4 227

Java DjVu

41 497

Xalan

338 316

Szü

kség

es

idő

[s]

Függőségi gráf építése

Absztrakt szintaxisgráf összeállítása

Modell tárolása


51

1.49 1.95 11.42

81.79

395.61

2 110.82

8.73

28.01

255.79

0

500

1000

1500

2000

2500

Physhun

4 227

Java DjVu

41 497

Xalan

338 316

Tim

e [

s]

Persisting the ASG

Transforming the Code into an ASG

Building the Dependency Graph


52

Nagyméretű forráskódtárak inkrementális statikus analízise

Technology

Transcript of Nagyméretű forráskódtárak inkrementális statikus analízise