Ezek a témák részben kapcsolódnak a Szoftvertechnológiai laboratóriumban folytatott kutatásokhoz, részben attól függetlenek. Számos programozási nyelvet (pl. C++, Scala, Java, stb.) érintenek, de közös bennük, hogy szükség van a fordítóprogramok működésének alapvető ismereteire, különösen az Absztrakt Szintaxisfa (AST) szerepének megértésére.
CodeChecker-rel kapcsolatos témák
A statikus elemzés egyik célja, hogy olyan potenciális hibákat próbál felfedezni a forráskódban, melyeket sem a fordító, sem a tesztek nem mutattak ki. Ilyen eszközök többek közt pl.
- CppCheck (nyílt forráskódú)
- Coverity (fizetős)
- klockwork (fizetős)
- Clang Static Analyzer (nyílt forráskódú)
A statikus elemzés során a programot nem futtatjuk, hanem csak a forráskódot elemezzük. Egy összehasonlítás található itt.
2016-ban adtuk ki az Ericsson Magyarországgal közösen fejlesztett, az LLVM/Clang C++ fordítón és a Clang Static Analyzer-en alapuló nyílt forráskódú eszközünket, melyet megtaláltok a Github-on is: CodeChecker. Felhasználóink, fejlesztő partnereink közt van a Sony, az Apple és a Google is.
Videó a 2015-ös EuroLLVM konferenciáról, ami ismerteti a Codechecker-t.
Előadás slide-ok a 2017 márciusi EUROLLVM konferenciáról, ami a fordítási egységek közötti ellenőrzés technikáit tárgyalja.
A lehetséges diplomamunkák kiterjednek a CodeChecker keretrendszer fejlesztésére, egyes ellenőrzési szabályok definiálására és implementálására, a Clang Static Ananlyzer fejlesztésére és egyéb feladatokra.
Új Codechecker C/C++ szabályok implementálása
Ehhez a feladathoz magabiztos C++ tudás és programozói tapasztalat szükséges. Lényegében korlátlan számban lehet úgy C/C++ szabályokat definiálni és implementálni. Potenciális szabályok implementálásához forduljanak hozzám e-mail-ben.
A Clang Static Analyzer fejlesztése
A Clang Static Analyzer jelenleg számos technikai korláttal rendelkezik. Ezek közül az egyik legfontosabb az, hogy elemzést csak egyetlen fordítási egységen belül tudja végrehajtani. Ezt és számos más hiányosságot lehetne (legalább részben) orvosolni a feladat során.
Codechecker integrálása fejlesztő környezetekbe
Hasznos, ha a programozó a fejlesztés során azonnali visszajelzést kap az elkövetett (potenciális) hibákról már a fejlesztő környezetben. A Codechecker rendszer jól definiált interfészen keresztül kommunikáni tud külső kliensekkel is. Ennek felhasználásával kéne integrálni a rendszert valamely fejlesztői környezetbe (pl. vi/gvim, emacs, stb.). Eclipse-hez egy erős prototípus már rendelkezésre áll itt. Az integrációs platformtól függően C++/Java tudás szükséges.
Statikus ellenőrzések más nyelveken
Elsősorban a Java és a Python nyelvhez léteznek elterjedt statikus ellenőrző rendszerek. Ilyen pl. a findbugs, amely a legelterjedtebb Java kódot ellenőrző rendszer. Szimbolikus végrehajtás alapon működő eszközként csak a NASA által kezdeményezett Java Pathfinder-t ismerjük.
Feladat lenne további eszközök megtalálása, összehasonlító elemzése és esetleges beintegrálásuk a CodeChecker-be.
CodeCompass-al kapcsolatos témák
A nagy szoftverek helyes megértésének támogatása, a pontos navigálás millió soros forráskódokban, a kód helyes és értető prezentálása, vizualizációja kritikus a nagy ipari rendszerek fejlesztése és karbantartása során. E célból hoztuk létre a CodeCompass nevű, nyílt forráskódú eszközt, amely sokmillió soros programok esetében is hatékonyan és precízen működik.
A lehetséges szakdolgozatok/diplomamunkák kiterjednek a CodeCompass funkcionalitásának bővítésére, a jelenlegi működés javítására vagy gyorsabbá tételére.
NOSql adatbázis
A CodeCompass jelenleg egy ORM leképezés után közönséges relációs adatbázisban (pl. postgresql) tárolja az adatokat. Mivel gyakran kell nem relációs jellegű kapcsolatokat tárolni ill. lekérdezni, érdemes lenne kipróbálni egy nem SQL alapú adatbázis implementációt is és összehasonlító elemzést végezni a hatékonyság szempontjából.
Editálhatóság, inkrementális parszolás
A CodeCompass beparszolja a kód jelenlegi állapotát és azt elérhetővé teszi a kliensek számára. Azonban a kód változásait (editálások) nem fogjuk látni a következős parszolásig. Ezt a problémát oldaná meg, ha a közbülső kód módosulások újra-parszolásra kerülnének sé megjelennének az adatbázisban.
Ez persze több problémát is felvet:
-
A módosult kódok (delták) csak a módosító számára szabad, hogy látszódjanak
-
A hatékonyság érdekében csak a módosult kódokat szabad újraelemezni.
LSP protokoll
A CodeCompass szerver és a kliensek egy JSON alapú nyelvfüggetlen speciális protokollon keresztül kommunikálnak. Időközben egy teljesen hasonló célú protokollt javasolt a Microsoft, a RedHat és más cégek. Az LSP potocol valószínűleg a hasonló célú megoldások kvázi-szabványává válik.
A feladat a CodeCompass szerver és kliens oldali kiegészítése az LSP protokollal. Ezáltal a CodeCompass elérhetővé válna egy sor kliensből (pl. Visual STudióból) is.
Clang language server
Az LSP fejlesztések egyik célja, hogy olyan intelligens szerver oldali megoldást hozzanak létre, amely képes kiszolgálni a kliensek igényeit. A CodeCompass számos ilyen tulajdonsággal már most is rendelkezik, érdemes lenne megpróbálkozni egy Clang LSP szerverré bővítésében.
Egyéb témák
C++ Serializáció támogatása
A C++-ban a szerializáció még nem megoldott probléma, de több igéretes kísérlet is van rá. Az egyik itt található: https://bitbucket.org/barczpe/oops/src/master/. Itt pedig egy előadás slidejai találhatóak róla: http://gsd.web.elte.hu/lectures/bolyai/2022/oops/SerializationInCpp.pdf. Jelenleg ez a könyvtár úgy működik, hogy az osztályokhoz kézzel kell hozzáadni a szükséges metainformációt. Példa az előadás 8 és 9 slide-ja. Mivel C++-ban nincsen és még jó ideig nem is lesz működő reflection, nincs más megoldás (hasonló elveken működik pl. a google test is). Cél: C++ attribútumokkal jelezni, hogy milyen osztályokat vagy mezőket akarunk szerializálni és egy clang alapú utilityvel automatikusan generálni ezt az információt. Az output vagy visszaíródik a forrásfileba a jelenlegi jelölésrendszer szerint vagy egy külső leíró állományba íródik ki. A feladatot egy Clang tools-al lehet megoldani, https://clang.llvm.org/docs/ClangTools.html, hasonlóan, mintha egy Tidy checkert írnál. A Clang felépíti az absztrakt szintaxis fát és onnan már a kiírás könnyű.
Energiahasználat forráskód szintű mérése
Számos IOT device esetében kritikus feladata az energiafogyasztás csökkentése. Bár vannak eszközök egy processzor eneriafelvételének mérésére, de pl. többszálas környezetben ezek gyakorlatilag használhatatlanok. Ugyancsak cél lenne az információk visszaképezése a forráskódra.
WCET – Worst Case Execution Time analízis
A program lehetséges végrehajtási idejének felső becslése a program futtatása nélkül.