Tartalomjegyzék

  1. Szakdolgozat Terv: MotoRun Auditálható Versenyértékelés
  2. Szakdolgozat Féléves Terv
  3. 1. Bevezető és a projekt háttere
  4. 2. A félév célkitűzései
  5. 3. Tervezett Architektúra
  6. 4. Főbb technikai kihívások
  7. 5. Ütemterv (14 hét)
Szakdolgozat Terv: MotoRun Auditálható Versenyértékelés Szakdolgozat Terv: MotoRun Auditálható Versenyértékelés

Szakdolgozat Terv: MotoRun Auditálható Versenyértékelés

2026. aug. 31. / 7 perc olvasás / Címkék: Szakdolgozat, Spring Boot, Compose Multiplatform

Szakdolgozat Féléves Terv

Téma: Auditálható versenyértékelés, adminisztráció és résztvevői eredményközlés a MotoRun rendszerben
Hallgató: Nagy Benedek (Szoftverfejlesztés/IIT specializáció)
Konzulens: Imre Gábor
Félév: 2026/27 Ősz

1. Bevezető és a projekt háttere

A MotoRun egy saját fejlesztésű, éles versenyen használt rendszer, amely a motoRun kétnapos motoros tájékozódási verseny adminisztrációját támogatja. A pontőrök az Android alkalmazásban NFC kártyával azonosítják a csapatokat, majd rögzítik az érkezési időt, a napi és teljes kilométeróra-állást, illetve a különleges eseményeket. A verseny helyszínén a mobilinternet nem tekinthető állandó erőforrásnak, ezért az alkalmazás továbbra is strict offline-first elven működik: minden adat először a telefon Room adatbázisába kerül, és csak ezután szinkronizálódik a központi rendszerrel.

Az Önálló Laboratórium során a korábbi Firebase Authentication + Firestore szerveroldalt saját fejlesztésű Java 25, Spring Boot 4 és PostgreSQL alapú moduláris monolitra cseréltem. Elkészült a JWT autentikáció, a szerveroldali konfliktusfeloldás, a kombinált push/pull szinkronizáció, a STOMP WebSocket broadcast, a Liquibase sémakezelés, a CI/CD pipeline és a Prometheus - Grafana monitoring stack. Az Android kliens Firebase SDK-i teljesen kivezetésre kerültek, miközben a korábban bevált lokális adatkezelés és a felhasználói folyamatok megmaradtak.

A verseny eredményének elkészítése azonban továbbra is egy manuális bizalmi határon halad át. A szervezők az alkalmazásból Google Sheets-be szinkronizálják az adatokat, majd azokat átmásolják egy több munkalapos Excel fájl megfelelő celláiba. A hibapontokat képletek számítják, de egy rossz tartomány, elcsúszott hivatkozás vagy hibás copy-paste úgy módosíthatja a végeredményt, hogy azt csak hosszú, manuális ellenőrzéssel lehet megtalálni. A probléma ezért nem pusztán a képletek automatizálása: egy olyan navigálható bizonyítékrendszerre van szükség, ahol bármely összesített érték visszakövethető a számítási lépéseken keresztül egészen a nyers pontőri bejegyzésekig.

2. A félév célkitűzései

A célom a teljes versenyértékelési folyamat digitalizálása úgy, hogy a szerver az adott versenyévhez kötött hivatalos szabályverzió alapján determinisztikusan számítsa a hibapontokat. Az eredmény nem egyetlen összegként készül el, hanem részletes számítási naplóként: kategóriánként, versenynaponként és szakaszonként tartalmazza a felhasznált bejegyzéseket, referenciaidőket és -távolságokat, eltéréseket, szervezői döntéseket és a keletkezett hibapontokat.

A szervezők számára Compose Multiplatform Web alapú adminisztrációs felület készül. A jelenlegi túlterhelt mobilos szervezői nézet helyett itt lehet majd konfigurálni a versenynapokat, pontőrhelyeket, szakaszokat, referenciaértékeket, csapatokat, felhasználókat és szerepköröket. Egy csapat-szakasz hőtérképről közvetlenül megnyitható lesz a hibapont-főkönyv, a két végpont nyers adata, a referenciaeltérés és a csapat teljes napi idővonala. A szervező a webes felületen javíthat hibás nyers bejegyzést, érvényteleníthet egy teljes szakaszt, egyedi elbírálást rögzíthet, majd ellenőrzött folyamatban publikálhatja vagy később indoklással módosíthatja az eredményt.

A résztvevők már a verseny előtt megkapják a csapatukhoz és versenyévükhöz tartozó aláírt linket és annak QR kódját. Publikáció előtt ez nem árul el hibapontot, referenciaértéket vagy a napi pontőrhelyek számát. Publikáció után ugyanaz a link a legfrissebb eredményverziót nyitja meg, ahol a csapat mobilbarát grafikonokon és a teljes numerikus levezetésen keresztül láthatja, hol nyerte vagy veszítette el a versenyt. A saját adatait beágyazott számításokkal rendelkező XLSX fájlban is exportálhatja, a linket pedig megoszthatja.

A dolgozat mérnöki súlypontja a bizonyítható működés. A rendszer csak akkor tekinthető késznek, ha a 2026-os verseny teljes adathalmazán visszaellenőrizhető, a webes folyamatokat Playwright valódi fejlesztői szerver ellen teszteli, a teljes backend és adatbázis elvesztése után végrehajtható a helyreállítás.

3. Tervezett Architektúra

A rendszer továbbra is a meglévő Android kliensből, egy Spring Boot moduláris monolitból, PostgreSQL adatbázisból és a monitoring infrastruktúrából áll. Ehhez csatlakozik az új Compose Multiplatform Web frontend, amely egy alkalmazáson belül biztosít szervezői és résztvevői felületet. Az Android alkalmazást nem migrálom multiplatform alapokra: a bevált offline-first adatfelvétel változatlan marad, csak egyes vizuális komponenseket és interakciós mintákat emelek át a webes felületre.

Versenykonfiguráció és jogosultságkezelés - A backend a versenyévet, versenynapokat, sorrendezett pontőrhelyeket, a közöttük lévő szakaszokat, referenciaértékeket, csapatokat, kilométeróra-kompenzációt és szabályverziókat explicit domain objektumokként tárolja. A webes admin felület a meglévő ORGANIZER, CHECKPOINT, TEAM és ADMIN szerepkörökre épül, új jóváhagyási hierarchia nélkül.

Eredményszámítás és bizonyítéklánc - A szerver a nyers bejegyzésekből, a versenykonfigurációból és a verziózott hivatalos szabályokból idempotens számítási eredményt készít. Minden hibapont-komponens megőrzi a forrásbejegyzések, operandusok, referenciaértékek, szabályok és szervezői döntések kapcsolatát. A nyers adatok és a származtatott eredmények lazán csatoltak: az újraszámítás soha nem írja át az eredeti pontőri megfigyelést.

Publikáció és résztvevői hozzáférés - A publikált eredményverzió megváltoztathatatlan snapshot. Késői adatjavítás esetén új, indoklással ellátott verzió készül, amely az előzőt leváltja, de nem törli. A magas entrópiájú bearer token pontosan egy versenyévhez és csapathoz biztosít hozzáférést; a szerveroldali publikációs szabály határozza meg, hogy az adott életciklusban mely mezők láthatók. A hozzáférések anonimizált azonosítóval mérhetők, a token rotálható és visszavonható.

Infrastruktúra és helyreállítás - Versenynapokon 10 percenként, egyébként naponta készül off-instance biztonsági mentés. Teljes instance- és adatbázisvesztés után az automatizált telepítés visszaállítja a konfigurációt és a korábbi adatokat, majd a teljes adatkészlettel rendelkező szervezői eszköz és a pontőrök kliensei normál szinkronizációval visszajátsszák a frissebb bejegyzéseket. Az entry push/pull elsődleges szolgáltatás; az eredményoldal, export, AI és háttérszámítás erőforrás-probléma esetén lekapcsolható másodlagos terhelés.

4. Főbb technikai kihívások

Determinisztikus pontszámítás és történeti validáció - A hivatalos szabályzat az autoritatív forrás, a meglévő Excel fájl csak összehasonlítási alap. A 2026-os adatokat minden csapatra, napra, szakaszra, hibapont-komponensre és helyezésre összevetem a szerver eredményével. Az eltéréseket Excel-hibára, forrásadat-javításra, kétértelmű szabályra vagy implementációs hibára bontom, majd minden eldöntött esetből permanens regressziós teszt készül.

Webes bizonyíték-navigáció és adatvédelem - A hőtérkép nem takarhatja el az adatokat egy látványos dashboard mögött. Minden cella kattintható, billentyűzettel elérhető és nyers adatig visszakövethető. A résztvevői nézetnek mobilon is használhatónak kell lennie, miközben a bearer link sem URL manipulációval, sem enumerációval nem adhat hozzáférést más csapat eredményéhez. A Compose Multiplatform Web jelen fejlesztési állapotát és Playwright vezérelhetőségét ezért a félév elején külön kockázati mérföldkőben ellenőrzöm.

Versenynapi prioritás és katasztrófa utáni rekonvergencia - Nincs olyan szerveroldali varázslat, amely egy offline telefonon maradt, még soha nem szinkronizált bejegyzést vissza tud állítani. A szolgáltatás 15 percen belül újra fogadhat szinkronizációt, de a teljes adathalmaz csak akkor tekinthető konzisztensnek, ha minden szükséges pontőri eszköz visszacsatlakozott.

AI mint másodvélemény - A determinisztikusan megjelölt gyanús értékekhez az LLM a csapat korábbi teljesítményét, az adott szakasz mezőnyadatait és a számítási bizonyítékot kapja meg. A résztvevő ugyanebből a keretrendszerből, de kizárólag a saját publikált eredménye és a nyilvános szabályok alapján kérhet magyarázatot.

5. Ütemterv (14 hét)

Az ütemterv 304 órás optimista alapra épül. Az első két hét a munkahelyi terhelés miatt egyenként csak körülbelül 8 órás, a további tizenkét hét 24 órás.

  • 1. hét (Szept. 7-13.) - Tervek véglegesítése, a hivatalos szabályok, a 2026-os nyers adatok és az Excel munkafüzet leltára. A szabály-, szélsőeset-, felhasználói folyamat- és bizonyítékkatalógusok kialakítása.

  • 2. hét (Szept. 14-20.) - Compose Multiplatform Web tesztelés: navigáció, mobilos elrendezés, billentyűzetes használat, hőtérkép/táblázat könyvtár támogatás és Playwright vezérlés. Minimális webes és E2E projektváz.

  • 3. hét (Szept. 21-27.) - Automatizált backup/restore implementáció.

  • 4. hét (Szept. 28-Okt. 4.) - Normalizált verseny, versenynap, pontőrhely, szakasz, csapat és referencia domain modell; minimális felhasználó- és szerepkör-kezelő webes vertical slice.

  • 5. hét (Okt. 5-11.) - Szabályverziók, megváltoztathatatlan számítási input snapshot, determinisztikus pontszámító mag és számítási eredetnapló implementálása. Az első teljes csapat/nap/szakasz számítás.

  • 6. hét (Okt. 12-18.) - A 2026-os adatok, eredmények betöltése és differenciális ellenőrzése, eltérések osztályozása, hibapont-kategóriák, összesítések, helyezések és determinisztikus validátor katalógus.

  • 7. hét (Okt. 19-25.) - Szervezői áttekintő, csapat-szakasz hőtérkép, hibapont-főkönyv és csapat-idővonal. Az aggregált értéktől a nyers adatig vezető út Playwright tesztje.

  • 8. hét (Okt. 26-Nov. 1.) - Közvetlen bejegyzésjavítás verzióütközés-védelemmel, determinisztikus anomália-felülvizsgálat, szakaszérvénytelenítés, csapatspecifikus elbírálás és versenyzárási állapotok.

  • 9. hét (Nov. 2-8.) - Megváltoztathatatlan publikáció és módosítás, csapathoz kötött bearer token és QR kód, szerveroldali láthatósági szabályok, mobilbarát résztvevői nézet, megosztás és hozzáférési statisztika.

  • 10. hét (Nov. 9-15.) - Szervezői és csapatonkénti XLSX exportok beágyazott képletekkel. Ha az eddigi mérföldkövek rendben, a közös LLM kontextus-összeállítási keretrendszer, a szervezői másodvélemény és a résztvevői magyarázat integrációja.

  • 11. hét (Nov. 16-22.) - Backup ütemezés, off-instance helyreállítási metaadatok, automatizált restore, kliens replay-restore.

  • 12. hét (Nov. 23-29.) - Integrált full-stack tesztsorozat: időben tömörített verseny, konkurens konfliktusok, teljes adatbázisvesztés, rekonvergencia, Playwright suite, ellenséges másodlagos terhelés és profilozás. Feature freeze november 29-én.

  • 13. hét (Nov. 30-Dec. 6.) - Hibák javítása, eredmények, korlátok, ábrák, dokumentáció.

  • 14. hét (Dec. 7-11.) - Dokumentáció.

Vissza a bloghoz