osztálydiagram - címke - it-tanfolyam.hu

Táblázatos hőtérkép készítése

2023. november 6. Szerző: Kaczur Sándor

Ebben a projektben táblázatos hőtérképet készítünk Java és JS nyelveken. Java programot készítünk az adatok véletlenszerű előállításához és a sablon alapján történő HTML fájl generálásához. JavaScript program fogja a grafikont megjeleníteni a weboldalon. Tervezünk, kódolunk, tesztelünk. Lássunk hozzá!

Mi az a hőtérkép?

A hőtérkép (heatmap) olyan grafikon, amely könnyen áttekinthetővé tesz nagy mennyiségű adatot úgy, hogy kategorizál/csoportosít és az előfordulások tartományai alapján különböző színeket rendel azokhoz. A szín hozzárendelése egy intervallumból történik. Például a világosabb a ritkább, a sötétedő szín az egyre gyakoribb értékeket jelenti. A tipikus hőtérkép kétdimenziós és az előforduló adatok mennyiségét, azok arányait, eloszlását, szóródását (nem szórását), gyakoriságát jeleníti meg. A hőtérkép gyors vizuális összefoglalást, áttekintést biztosít. A projekt során sorokból és oszlopokból álló táblázatos hőtérképet készítünk.

A táblázatos hőtérkép nem összekeverendő a következő két megközelítéssel:

Ha az adatok lokációhoz kötődnek és térképen jelennek meg, akkor azt tematikus térképnek nevezzük. Erről már blogoltam korábban, lásd: Céline Dion – Courage World Tour, amikor az énekesnő USA-beli államokban előforduló koncertjeinek számát jelenítettem meg. Ehhez hasonlók az amerikai elnökválasztás során használt tematikus térképek, amelyek a(z egyes) jelöltek szavazatainak arányát ábrázolják meg szintén államonként.
Ha az adatok webergonómiához, bannervaksághoz, inkább fókuszban lévő tartalmakhoz, felhasználói élmény (UX) tervezéshez kötődnek, akkor a weboldal grafikus elemeihez (azok pozíciója) alapján rendelünk hozzá színeket attól függően, hogy mennyi ideig nézi azt a felhasználó.

Mi a feladat (koncepcionálisan)?

Adott egy konditerem, amely hétköznapokon egy megadott időintervallumban használható. Ehhez kulcsot kell felvenni és leadni. Az első belépő nyitja és az utolsó távozó zárja az ajtót. A teremhasználat offline nyilvántartott, így nehézkes bármiféle kimutatás, statisztika. A „menet közbeni” jövés-menést nem tudjuk követni. Természetesen adott számos szabály (felelősség, biztonság, balesetvédelem, létszámkorlát), amit most nem részletezek.

Elhelyezünk az ajtó mellett, belülről egy belépéshez és egy távozáshoz tartozó QR kódot. Készítünk egy egyszerű mobil alkalmazást és megkérjük a konditermek használóit, hogy belépéskor és távozáskor „csekkoljanak”. Anonim gyűjtjük a belépések és távozások időpontját (valahol egy szerveren, bármilyen fájlban, adatbázisban).

A konditermek használatára vonatkozó összesített adatokat könnyen átlátható módon szeretnénk weboldalon megjeleníteni: heti bontásban, a nyitva tartás időszakát órás blokkokra bontva az igénybevételtől függően jelenjenek meg az adatok táblázatos hőtérképen.

Ez az állapot átmeneti. Segítheti a konditermekbe tervezett – egyéni használattól független – események ütemezését. Ezeket akkor lenne célszerű időzíteni, amikor nem, alig, vagy kevésbé használt, foglalt az adott konditerem. A továbbfejlesztés következő állapotában könnyen lecserélhető a QR kód RFID alapú proximity kártyára, proxy kulcstartóra: először csak a jelenlét nyilvántartásához, később akár az ajtó nyitásához is.

Mit valósítunk meg mindebből Java nyelven?

Egyetlen konditeremre fókuszálunk. A hétköznaponként nyitva tartás legyen 16 órától 21 óráig. Aki edzésre jön, véletlenszerűen 20 és 40 perc közötti időszakot tölt a konditeremben. 16 órától lehet belépni. Az utolsó belépés 20:40-kor lehet (érdemes). 21 órakor mindenki elhagyja a konditermet. Nem fordul elő, hogy valaki nem jelzi a belépését vagy a távozását. Mivel anonim a nyilvántartás, így elegendő a dátum/időhöz, időbélyeghez egyetlen állapotot tárolni: be vagy ki. Valaki belépett nyitáskor vagy valamikor utána, majd távozott 20-40 perccel később, de legfeljebb záráskor.

A szükséges adatokat véletlenszerűen állítjuk elő. Egy hétre vonatkozó adatokat generálunk. Ezek a fenti paramétereknek megfelelő, összetartozó belépéshez és távozáshoz köthető időpontok. Kiegészítve a napok ciklusban való léptetésével hétfőtől péntekig. Az adatokat feldolgozva, összegyűjtve, csoportosítva, kategorizálva olyan (kimeneti) formátumra alakítjuk, amely kompatibilis a táblázatos hőtérkép adatmodelljével (bemenetével). Mindez Java nyelven valósul meg.

Mi történik JavaScript nyelven?

A webes megjelenítéshez szükséges egy HTML fájl, amelyben beágyazva található meg egy téglalap alakú területként megjelenő táblázatos hőtérkép. Ez sokféleképpen testre szabható: adható hozzá felirat, beállítható a sorokhoz és oszlopokhoz tartozó szöveg és a táblázat celláiban megjelenő értékek, adott a lebegő, az egér kurzor helyzetétől függő – cellánként különböző – jelmagyarázat, és persze mindennek van formátuma (betűtípus, méret, szín, igazítás, kitöltés). A fix, adatoktól nem függő beállításokat tartalmazó weboldalt sablonként elkészítjük. Mindez JavaScript nyelven történik. Ezután Java program a weboldal sablonját kiegészíti (cseréli, behelyettesíti, feltölti) a szükséges adatokkal.

Hogyan alakul az időintervallumok átfedése?

A konditerem használatának alakulását követjük, amihez táblázatos hőtérképet készítünk. Ehhez a nyitva tartás időintervallumát órás blokkokra bontjuk. Blokkonként összesítjük a jelenlétet, azaz megszámoljuk, hogy éppen akkor hányan veszik igénybe a konditermet, hányan vannak jelen/benn.

A konkrét paraméterektől függően az alábbi képen látható 3 eset egyike fordulhat elő. A és B jelöli az órás blokk elejét és végén, tehát ez 60 perces intervallum. Tarthat például: 16:00:00-16:59:59-ig. X és Y jelöli a jelenlét intervallumát, azaz a belépés és távozás időpontjait. Ez 20 és 40 perc között alakul. Haladjunk balról jobbra az ábrán.

Az első esetben ugyanarra az órára esik a belépés és a távozás. Ez az eset egyértelmű. A másik két esetben átfedés van több órás blokk között, mert különböző órára esik a belépés és a távozás. El kell dönteni, hogy ekkor hogyan összesítjük a jelenlétet. Válasszunk az alábbi két módszer közül:

Az első módszer szerint mindkét órához – ahol átfedés van – összesítjük a jelenlétet 1-1 főként, hiszen ha nem is végig, de jelen volt mindkét órás blokkban. Például: egy 16:50:00-17:20:00 jelenlétet a 16 és 17 órás blokkban is figyelembe veszünk.
A második módszer szerint időarányosan tesszük mindezt, azaz súlyozunk aszerint, hogy milyen hosszú jelenlét esik az egymást követő órákban. Például: egy 16:50:00-17:20:00 jelenlétet a 16 órás blokk esetében egyharmad, a 17 órás blokk esetében kétharmad a jelenlét adott órára eső aránya, súlya.

Az első módszert valósítjuk meg. Ez a döntés jelentősen befolyásolja, hogyan kell értelmezni később az elkészült táblázatos hőtérképet.

Objektumorientált tervezés

A koncepcionális terv alapján modellezünk. A szükséges adatok tárolására és alapfunkcióira fókuszálunk. Az osztály tárolja az összetartozó adatokat és megvalósít rajtuk értelmezhető műveleteket. Az időintervallum/időtartam kezelését a Duration ősosztály oldja meg. Tárolja a start és stop – naptól független időpontokat tároló – adatok és a rájuk vonatkozó FORMAT – megjelenítéshez kötődő – konstanst. Biztosítja a szükséges műveleteket: konstruktor, getterek, megvalósítja az időintervallumok átfedését az isOverlapped() függvénnyel, valamint ad szöveges reprezentációt a toString() függvénnyel. Az ősosztályból öröklődik az utódosztály. A DurationMap osztály a naptól független időpontokat kibővíti a hozzájuk tartozó day nappal, valamint képes tárolni az összesített, megszámolt jelenlétet a count változóban. Részt vesz a megszámolás folyamatában azzal, hogy lépésenként meghívható az incrementCount() eljárása.

A java.time csomagbeli LocalTime osztály képes a dátumtól független, napon belüli időpont tárolására és biztosít néhány alapvető funkciót a kezelésükre. Az adattárolás a napon belül eltelt időn alapul és nekünk (bőven) elegendő a másodperc alapú megjelenítés. A DateTimeFormatter alkalmas ezen időpontok formátumának tárolására, például óó:pp:mm alakban.

A Duration osztályból annyi objektum készül, ahány jelenlét adódik véletlenszerűen. Akár több száz is lehet. A DurationMap osztályból generált objektumok száma jóval kevesebb. Heti 5 napra, napi 5 órás blokkra 25 db készül belőle.

A vezérléshez kötődő osztály tervezését nem részletezem.

Íme a Java forráskód

public class Heatmap {

private final DayOfWeek[] WORKDAYS=new DayOfWeek[] {

DayOfWeek.MONDAY, DayOfWeek.TUESDAY, DayOfWeek.WEDNESDAY,

DayOfWeek.THURSDAY, DayOfWeek.FRIDAY};

private final LocalTime ENTER_START_TIME=LocalTime.of(16, 0, 0);

private final LocalTime ENTER_STOP_TIME=LocalTime.of(20, 40, 0);

private final LocalTime EXIT_TIME=LocalTime.of(20, 59, 59);

private final DateTimeFormatter FORMAT=

DateTimeFormatter.ISO_LOCAL_TIME;

private final Path HEATMAP_TEMPLATE_FILE=

Paths.get("./files/heatmap-template.html");

private final Path HEATMAP_FILE=Paths.get("./files/heatmap.html");

private ArrayList<DurationMap> durationMapAllList=new ArrayList<>();

public Heatmap() {

overlapTest();

createHeatmapFile();

}

private void overlapTest() {

for(DayOfWeek day: WORKDAYS) {

LocalTime intervalStart=ENTER_START_TIME;

LocalTime intervalStop=

intervalStart.plusHours(1).minusSeconds(1);

ArrayList<DurationMap> durationMapDayList=new ArrayList<>();

for(int i=1; i<=5; i++) {

DurationMap interval=

new DurationMap(day, intervalStart, intervalStop);

durationMapDayList.add(interval);

intervalStart=intervalStart.plusHours(1);

intervalStop=intervalStop.plusHours(1);

}

ArrayList<Duration> durationList=new ArrayList<>();

for(int i=1; i<=10; i++) {

int startSec=ENTER_START_TIME.toSecondOfDay(),

stopSec=ENTER_STOP_TIME.toSecondOfDay();

int randomSec=

(int)(Math.random()*(stopSec-startSec+1)+startSec);

LocalTime startTime=LocalTime.ofSecondOfDay(randomSec);

int presenceMin=(int)(Math.random()*21+20);

LocalTime stopTime=LocalTime.ofSecondOfDay(Math.min(

startTime.toSecondOfDay()+presenceMin*60,

EXIT_TIME.toSecondOfDay()));

durationList.add(new Duration(startTime, stopTime));

}

durationMapDayList.stream().forEach((durationMap) -> {

durationList.stream().

filter((duration) -> (duration.isOverlapped(durationMap))).

forEach((duration) -> {

durationMap.incrementCount();

});

durationMapAllList.addAll(durationMapDayList);

}

private void createHeatmapFile() {

String heatmapData=durationMapAllList.stream().

map(DurationMap::toString).collect(Collectors.joining(",\n"));

try {

String html=Files.readAllLines(HEATMAP_TEMPLATE_FILE).stream().

collect(Collectors.joining("\n"));

html=html.replace("##HEATMAP_DATA##", heatmapData);

Files.write(HEATMAP_FILE, html.getBytes(),

StandardOpenOption.CREATE);

}

catch(IOException e) {

e.printStackTrace();

}

public static void main(String[] args) {

new Heatmap();

}

A Java forráskód minden megtervezett funkciót megvalósít, támogatva a koncepciót. Most nem részletezem a működését.

A véletlenszerűen előállított adatok

A lista görgethető:

{x: "hétfő", y: "16:00:00-16:59:59", heat: 4},

{x: "hétfő", y: "17:00:00-17:59:59", heat: 6},

{x: "hétfő", y: "18:00:00-18:59:59", heat: 9},

{x: "hétfő", y: "19:00:00-19:59:59", heat: 6},

{x: "hétfő", y: "20:00:00-20:59:59", heat: 6},

{x: "kedd", y: "16:00:00-16:59:59", heat: 6},

{x: "kedd", y: "17:00:00-17:59:59", heat: 10},

{x: "kedd", y: "18:00:00-18:59:59", heat: 6},

{x: "kedd", y: "19:00:00-19:59:59", heat: 7},

{x: "kedd", y: "20:00:00-20:59:59", heat: 3},

{x: "szerda", y: "16:00:00-16:59:59", heat: 5},

{x: "szerda", y: "17:00:00-17:59:59", heat: 9},

{x: "szerda", y: "18:00:00-18:59:59", heat: 5},

{x: "szerda", y: "19:00:00-19:59:59", heat: 7},

{x: "szerda", y: "20:00:00-20:59:59", heat: 7},

{x: "csütörtök", y: "16:00:00-16:59:59", heat: 4},

{x: "csütörtök", y: "17:00:00-17:59:59", heat: 6},

{x: "csütörtök", y: "18:00:00-18:59:59", heat: 11},

{x: "csütörtök", y: "19:00:00-19:59:59", heat: 7},

{x: "csütörtök", y: "20:00:00-20:59:59", heat: 5},

{x: "péntek", y: "16:00:00-16:59:59", heat: 4},

{x: "péntek", y: "17:00:00-17:59:59", heat: 8},

{x: "péntek", y: "18:00:00-18:59:59", heat: 4},

{x: "péntek", y: "19:00:00-19:59:59", heat: 7},

{x: "péntek", y: "20:00:00-20:59:59", heat: 4}

A weboldal sablonja

HTML és JavaScript nyelvű forráskód vegyesen. A Java program a fájl 31. sorában lévő ##HEATMAP_DATA## szöveget cseréli le a táblázatos hőtérkép megjelenítéséhez szükséges véletlenszerűen előállított adatokra.

<html>

<head>

<title>Heatmap in JavaScript</title>

html, body, #container {

width: 80%; height: 80%; margin: 20pt; padding: 20pt;

}

</style>

</head>

<body>

anychart.onDocumentReady(function () {

let chart=anychart.heatMap(getData());

chart.title("Hogyan alakul a konditerem látogatottsága?");

chart.tooltip().useHtml(true).titleFormat(function () {

return "Látogatottság: "+this.heat;

}).format(function () {

return (

'<span style="color: #CECECE">Nap: </span>'+this.x+"<br/>"+

'<span style="color: #CECECE">Időtartam: </span>'+this.y

);

});

chart.container("container");

chart.draw();

});

function getData() {

return [

##HEATMAP_DATA##

];

}

</script>

</body>

</html>

További részletekért, beállításra vonatkozó, testre szabási lehetőségekért érdemes tanulmányozni az AnyChart dokumentáció Heat Map Chart fejezetét.

Az eredmény

Az előállított weboldalt böngészőben megjelenítve ezt kaphatjuk eredményként (vagy a véletlenszerűen generált adatoktól függően hasonlót):

A táblázatos hőtérkép hasznos eszköz. Elemezve könnyen döntéseket hozhatunk a koncepcionális tervezés során vázoltak alapján.

Továbbfejlesztési lehetőségek

Lehetne több konditerem is. Ekkor rögtön felmerül az összehasonlítás lehetősége, egyben igénye is.
Lehetne hétköznaponként eltérő a konditerem nyitva tartása.
Az időpontok kezelési precíz. Egy másodpercen múlik, hogy nem fedik át egymást. Az időpontok megjelenítése lehetne óó:pp alapú is.
Az időintervallumok jelenleg állandóak, mindig 1 órásak. Könnyen megoldható lenne, hogy dinamikusak legyenek: például a népszerűbb időszakok felbonthatók lennének két 30 perces blokkra. A népszerűség értelmezhető minden nap (héten) másképp. Egyszerű képlettel: átlag felett, medián felett.
Általánosíthatnánk a létesítménygazdálkodáshoz kötődő erőforrást nem (feltétlenül) helyhez kötött, mozgatható, kölcsönözhető eszközökre is: hangszer, projektor, stúdió felszerelés.
Másképpen valósulna meg az adatgyűjtés, ha egyetlen QR kód állna rendelkezésre és back-end helyett a „mobil alkalmazás emlékezne” a belépésre és távozásra. Ez jelentheti legalább az aznapi adatokat, de tárolható historikusan is.
Hibát is kellene, lehetne kezelni. Például a kiléptetés lehetne automatikus a nyitva tartás végén. A jelenlét igazából igaz-hamis állapot: ha eddig hamis volt és történt valami, akkor igaz lesz és fordítva. Ha van mögötte állapotmegőrző emlékezet (mivel programozunk, így nyilvánvalóan azonnal objektumra gondolunk, vagy annak valamilyen fájlba vagy adatbázisba történő leképezésére).
A nyilvántartás könnyen megvalósítható személy hozzárendelésével, azaz lehetne nem anonim is a jelenlét.
Egymást átfedő időpontok esetén (ha nincsenek a hosszukra vonatkozó korlátozó feltételek) általánosítva 6 eset fordulhat elő. Például ha a jelenlét lehetne 60 percnél hosszabb, de 120 percnél rövidebb is, akkor nem lenne elegendő a fenti 3 esetet kezelni a jelenlét összesítése során.
Valósítsuk meg az időintervallumok átfedésénél bemutatott második – időarányos – módszert!
A napi jelenlét 20 fővel valósul meg a programban. Lehetne ez a paraméter is véletlenszerű, például 15-30 fő között, vagy esetleg népszerűbb a péntek.
Jelenleg a táblázatos hőtérkép statikus. Csak a (befejezett egész heti) múltbeli adatokat tudja megjeleníteni. Az aktuális, jelenlegi állapothoz szinkronizáció, ütemezés kell. Óránként (a blokkok végén automatizáltan), de akár 5 percenként is aktualizálható a hőtérkép.
A táblázatos hőtérkép megjelenítése önálló weboldal helyett beágyazható widget felületén is történhet.
Többféleképpen is készítettünk már grafikonokat, íme néhány a szakmai blogunkból: Kockadobás kliens-szerver alkalmazás, Sankey-diagram készítése, JFreeChart grafikon készítése.

A bejegyzéshez tartozó forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A projektfeladat – attól függően, milyen szinten valósítjuk meg – kapcsolódhat több tanfolyamunk tematikájához. A fenti forráskód a Java SE szoftverfejlesztő tanfolyam 17-28. óra: Objektumorientált programozás és a 37-44. óra Fájlkezelés alkalmaihoz kötődik. Ha többrétegű, elosztott alkalmazásként valósítjuk meg, akkor a Java EE szoftverfejlesztő tanfolyam a 9-16. óra: XML és JSON feldolgozás, dinamikusan generált weboldalba beépítve a 33-40. óra: Java Server Pages alkalmaihoz kapcsolódik. Ha fájlok helyett egyszerű adatbázist használnánk, akkor a Java SE szoftverfejlesztő tanfolyam 45-52. óra: Adatbázis-kezelés JDBC alapon, ha objektumrelációs leképezéssel oldanánk meg, akkor a Java EE szoftverfejlesztő tanfolyam 25-32. óra: Adatbázis-kezelés JPA alapon alkalmakhoz kötődhet.

Kutatók éjszakája 2023

2024. augusztus 10.2023. szeptember 29. Szerző: Kaczur Sándor

A Kutatók éjszakája nemzetközi rendezvénysorozat 2005-ben indult. Magyarország 2006-ban csatlakozott. Azóta évről-évre egyre több intézmény nyitja meg hazánkban kapuit, szervez érdekes programokat, sok-sok településen, több száz helyszínen, több ezer eseményt meghirdetve sok tízezer érdeklődő/résztvevő látogatónak biztosít tartalmas estét.

Bár a kezdeményezés elsősorban a kutatói pálya népszerűsítését szolgálja, ezért leginkább a tizen- és huszonévesekre számít, az események vonzók és elég érdekesek ahhoz, hogy a kisgyerekektől a legidősebbekig mindenki megtalálja a számára izgalmas programokat. Korábban nagyobb felsőoktatási intézmények és kutatóintézetek szerepeltek döntően, de az utóbbi néhány évben egyre több kisebb intézmény, tehetséggondozással foglalkozó középiskola, cég, egyesület is csatlakozott a rendezvényhez. A Kutatók éjszakája rendezvény minden meghirdetett programja ingyenes.

Rendezvényünk plakátja

Az it-tanfolyam.hu 2023-ban is hirdetett programokat az eseményhez kötődően. Programjainkat elsődlegesen követőinknek, aktív hallgatóinknak és az alumni csoportunkban hirdettük meg, de persze nyílt rendezvényként valósult meg. Az eseményekre regisztrálni kellett a weblapon. A regisztrációs időszak másfél hétig tartott, szeptember 18-28-ig. Programjainkra szeptember 29-én 21:00-23:55-ig került sor.

21:00-21:30 – Kiss Balázs: Az ipari forradalom evolúciója: ipar 4.0 és 5.0, okos gyár
Az előadó áttekinti az ipari forradalom evolúcióját. Címszavakban: ipar 1.0 – gépek gőzzel/vízzel és ipari termelés (1780), ipar 2.0 – villamosítás és sorozatgyártás (1870), ipar 3.0 – automatizálás számítógépekkel/elektronikával (1970), ipar 4.0 – digitális transzformáció, AI, IoT, adatelemzés, kiberfizikai rendszerek (jelenleg), ipar 5.0 – emberközpontú megközelítés, fenntarthatóság, fokozott ellenálló képesség (legújabb iteráció). Az Európai Parlament 2016-os állásfoglalásából kiindulva, az okos gyárak koncepciójának ismertetésével folytatva, valamint praktikus tanácsok is előkerülhetnek zárásként – igény szerint. Az előadó évek óta foglalkozik okos architektúrák fejlődésének történetével, koncepciójával, szoftveres integrációjával és konfigurációjával. Szívesen osztja meg gondolatait, kutatási eredményeit a témáról, beszél saját kisebb és nagyobb léptékű okos projektjeiről. A program a Java tanfolyamaink orientáló moduljához kötődik.

21:35-22:10 – Kaczur Sándor: Algoritmusok vesebeteg-donorok párosítására
Hogyan működik 2007 óta Nagy-Britanniában a vesebeteg-donorok párosítása? Sima csere 2 pár esetén adódik. 3 pár esetén körbeadják a vesét egymásnak – ez már jóval összetettebb. A felépített óriási adatbázisban akár több száz lehetőség is adódhat. A probléma megfelelő párosítási algoritmus és számítógép nélkül, pusztán emberi erővel megoldhatatlan lenne. Az implementált algoritmus futási ideje mindössze 30 perc. A párosítást követően a következő lépés a műtétek egyidejűsége, és a donor szervek „utaztatása” minden lehetséges földi, vízi, légi úton és lehetséges közlekedési eszközzel. Hogyan működik mindez a gyakorlatban? Milyen korlátok, problémák vannak? Milyen adatok alapján dönthető el a betegek „kompatibilitása”? Ezek közül mi kapcsolódik az egészségügyhöz és a szállításhoz? Az előadó próbál válaszokat adni, de lehet, hogy a végén több lesz a kérdés, mint a válasz. Vajon egyáltalán felmerül a párosítási algoritmus hatékonysága ekkora társadalmi hasznosság mellett? A tavalyi előadás kibővült: újabb algoritmusokkal egészült ki. A program a Java tanfolyamaink orientáló moduljához kötődik.

22:15-22:40 – Kaczur Sándor: Naprendszer szimuláció: elméleti háttér, objektumorientált tervezés, megvalósítás, tesztelés Java és JavaScript nyelveken
Az előadó ismerteti a feladatspecifikációt, ennek objektumorientált tervezését, a térben elhelyezkedő objektumok pozíciójának leképezését a síkra, a tömegvonzás közelítő kiszámítását a modelltérben, és a megjelenítést. A megvalósítás során különböző technológiákat hasonlít össze, például HTML5 canvas és JavaScript, Java2D. A felépítés a szoftverfejlesztés klasszikus lépéseinek megfelel. Némi tesztelés is előkerül. Adódnak továbbfejlesztési lehetőségek is. Elengedhetetlen némi matematikai, fizikai háttér áttekintése látványosan (animáció, szimuláció, gamifikáció) történik. A program a Java SE szoftverfejlesztő tanfolyamunk tematikájához kötődik.

22:45-23:10 – Falus Anita, Tóth-Szabó Tamás, Horváth Zoltán Miklós: Karrierváltás után – az álláskeresés és néhány hónap KKV-s tapasztalatai szoftverfejlesztőként
Mennyire könnyű ma szoftverfejlesztőként elhelyezkedni szakirányú felsőfokú végzettség nélkül? Milyen kihívásokkal találkozhatunk a felvételi folyamat során? Milyen elvárásokat támasztanak a munkaadók egy junior szakemberrel szemben? Hogyan telnek a beilleszkedés után a hétköznapok junior fejlesztőként kis létszámmal működő informatikai profilú kisvállalkozásnál? A tanfolyamainkon 2021-ben és 2022-ben végzett előadók karrierváltó junior szakemberként személyes tapasztalataikról számolnak be és válaszolnak a kérdésekre. A program a Java tanfolyamaink orientáló moduljához kötődik.

23:30-23:55 – Szegedi Kristóf, Hollós Gábor: Gondolkodjunk logikusan!
Az előadás során áttekintjük az intelligencia, a kreatív problémamegoldó és logikus gondolkodás összefüggéseit és izgalmas feladatokból válogatva közösen megoldunk néhány fejtörő feladatot. Néhány példa: Hány éves a kapitány?, CHOO + CHOO = TRAIN, Logikus gondolkodás teszt. Minden feladathoz adunk rávezető példákat – ha esetleg egyik-másik nem menne, akkor ebből ki fog derülni, hogy miket érdemes gyakorolni ahhoz, hogy sikerüljön.

A programjaink népszerűek voltak. 43 érdeklődő látogatót fogadtunk. Többségükben végig velünk tartottak. Elgondolkodtató párbeszéd alakult ki a vesebeteg-donorok párosításáról, valamint sok-sok kreatív ötlet került elő a logikus gondolkodás program fejtörőivel kapcsolatosan. Néhányan megragadták a lehetőséget, hogy több budapesti helyszínt is meglátogassanak – ahogyan ez megszokott a Kutatók éjszakája rendezvényeken hosszú évek óta. Kellemes hangulatban, tartalmasan töltöttük együtt az időt, aminek igazán örülök.

Szeretném megköszönni az előadó oktató kollégák és alumni hallgatóink színvonalas munkáját, igényes felkészülését. Köszönjük mindenkinek, aki részt vett a Kutatók éjszakája 2023 rendezvényünkön. Az előadások prezentációit tanfolyamaink hallgatói számára – a témához kapcsolódó témakörökhöz, ILIAS-ra feltöltve – tesszük elérhetővé.

Naprendszer szimuláció – megvalósítás Java nyelven

2023. december 28.2023. március 10. Szerző: Friedel Attila

Naprendszer szimulációt terveztünk és valósítottunk meg Java nyelven, amit három részből álló blog bejegyzés sorozatban mutatunk be (ez a 3. rész):

Naprendszer szimuláció 1. rész – elméleti háttér
Naprendszer szimuláció 2. rész – objektumorientált tervezés
Naprendszer szimuláció 3. rész – megvalósítás Java nyelven

A Naprendszer szimuláció megvalósítása Java nyelven

Fejlesztőeszközként a Java Swinges projekthez a JDK+JRE aktuális verziót támogató NetBeans IDE-t használtuk. Hibakeresés során, a modell adatainak ellenőrzését és a működés helyességének egyszerű tesztelését, debuggolást konzolra történő szöveges kiírással oldottuk meg. A megvalósítás során az előre megtervezett osztálydiagramok alapján készült el Java nyelven a forráskód. Az MVC modell szerint elkülönített programrészek külön csomagokba kerültek, ezzel is kiemelve a funkciók szerinti szétválasztást – eleget téve a terv követelményeinek.

Részlet a Java forráskódból

Megmutatjuk a Java forráskódnak azt a részét, ami megvalósítja az elméleti háttérnél ismertetett transzformációs mátrix alkalmazását X tengely körüli elforgatásra, a nézőponttól való távolság függvényében az égitest látható méretének kiszámítását, valamint a 3D→2D leképezést.

Point3D forog = new Point3D(

b.getPozicio().getX(),

b.getPozicio().getY() * Math.cos(forogZ) +

b.getPozicio().getZ() * Math.sin(forogZ),

-1 * b.getPozicio().getY() * Math.sin(forogZ) +

b.getPozicio().getZ() * Math.cos(forogZ));

int egitestMeret = (int)(

(AdatInterfesz.MELYSEG * b.getSize()) /

(AdatInterfesz.MELYSEG - forog.getZ()));

Point2D kepXY = new Point2D(

(forog.getX() * AdatInterfesz.MELYSEG /

(AdatInterfesz.MELYSEG - forog.getZ()) /

size) + origo.getX() - egitestMeret / 2,

(forog.getY() * AdatInterfesz.MELYSEG /

(AdatInterfesz.MELYSEG - forog.getZ()) /

size) + origo.getY() - egitestMeret / 2);

A teljes és megjegyzésekkel ellátott forráskód ILIAS e-learning tananyagban hozzáférhető, letölthető, tesztelhető tanfolyamaink résztvevői számára.

Az elkészült Java Swinges alkalmazás felhasználói felülete

Tapasztalatok

A Java nyelv erősen típusos, így a kötelező és sok lebegőpontos/egész átalakítás miatt észrevehető, hogy a legkisebb égitest (Hold) kissé ugrál.
Az OO szempontból szép Java megvalósítás könnyen módosítható és bővíthető, a funkciók jól csoportosítottak, a felelősségi kör egyértelműen meghatározott.
A projekt megtervezéséhez és elkészítéséhez magasabb szintű absztrakciós készség szükséges.
A példaprogram alkalmas a különböző szakterületek, témakörök (matematika – lineáris algebra, fizika, számítógépes grafika, virtuális valóság modellezése) közötti kapcsolatok felismertetésére, megerősítésére, a (legalább részben) egymásra épülések felderítésére.
A terv átgondolásával, implementálásával gyors, látványos eredmény érhető el, a sikerélmény hamar jelentkezik.

Továbbfejlesztési lehetőségek

Célszerű ötlet a hardveres gyorsítás és 3D megjelenítés megvalósítása.
Felkínálható lenne a felhasználó számára több paraméter módosítása.
Az égitestek lehetnének textúrázhatók is.
Az égitestek pozíciója kiinduló helyzetben lehetne valós.
A szimuláció szükség esetén lehetne elindítható, leállítható, újraindítható, gyorsítható, lassítható.
A terv könnyen implementálható lehet Java3D technológia alkalmazásával, illetve DirectX és/vagy OpenGL támogatással is.
Az égitestek pozíciója és mozgása demonstrálhatna/modellezhetne nevezetes együttállást is, külön esettanulmányként.
A program paraméterezhető lehetne konfigurációs fájlból (amelynek formátuma tetszőleges: INI, XML).
Fejlettebb matematikai modell is alkalmazható lenne.

Forrás

Friedel, A.; Kaczur, S. (előadó: Friedel, A.): Naprendszer szimuláció a Virtuális valóság modellezése tantárgyban, Informatika Korszerű Technikái Konferencia, Dunaújváros, Dunaújvárosi Főiskola, 2012. november 16-17. (előadás hazai konferencián)
Friedel, A.; Kaczur, S.: Naprendszer szimuláció a Virtuális valóság modellezése tantárgyban, Cserny, L.; Hadaricsné Dudás, N.; Nagy, B. (szerk): Dunakavics Könyvek 2. – Az Informatika Korszerű Technikái, Dunaújvárosi Főiskola, Új Mandátum Könyvkiadó, 2014, ISBN 978 963 287 069 4, ISSN 2064-3837, p. 72-84 (magyar nyelvű szakcikk)

Naprendszer szimuláció – objektumorientált tervezés

2023. december 28.2023. február 7. Szerző: Friedel Attila

Naprendszer szimulációt terveztünk és valósítottunk meg Java nyelven, amit három részből álló blog bejegyzés sorozatban mutatunk be (ez a 2. rész):

Naprendszer szimuláció 1. rész – elméleti háttér
Naprendszer szimuláció 2. rész – objektumorientált tervezés
Naprendszer szimuláció 3. rész – megvalósítás Java nyelven

A Naprendszer szimuláció objektumorientált tervezése

A Naprendszer égitestjeinek ábrázolása a valódi világban előforduló méretük és távolságuk szerint történik azért, hogy a szimuláció stabil legyen. A példában a Nap és a három belső bolygó szerepel, valamint a Hold. Utóbbi igazolja, hogy nem csak Nap középpontú égitestekre működőképes a modell. A szimuláció diszkrét lépések véges sorozataként valósul meg, az egyes lépések között az égitestek a virtuális térben egyenes vonalú egyenletes mozgást végeznek. Olyan lépésközt kell választani, amely rövid idő alatt kellően nagy változást képes bemutatni, ilyen például az 1 számítási ciklus / 1 nap érték. 10 képkocka / másodperces megjelenítést feltételezve – melyet egy időzítő biztosít – egy virtuális év kb. 37 másodperc alatt telik el, vagyis a Föld ennyi idő alatt tesz meg egy teljes fordulatot a Nap körül. Az égitestek kezdő pozíciója fiktív, nem függ konkrét dátumtól, együttállástól, méretük a jobb láthatóság érdekében torzított.

A program indításakor a szimuláció automatikusan indul, és nincs lehetőség a leállításra. Az alkalmazás felületének tetején foglalnak helyet a kezelő nyomógombok, a többi részt a megjelenítés/transzformált modelltér tölti ki. Futás közben – egyszerű eseménykezelést megvalósítva – lehet változtatni a méretarányt és a nézőpontot, így az ekliptika síkját felülről és elbillentve is ábrázolhatjuk.

Kivételkezelés nem szükséges a programhoz, mert ez egy önálló demonstrációs eszköz, nem épül rá több elem, nem érhetőek el a szolgáltatásai külső programok számára.

Meghatározott cél és a szempontok: a Java projektben a csomagokat az MVC szerint hozzuk létre, a funkciókat logikusan osszuk szét, csoportosítsuk, tartsuk be az objektumorientált szemléletmód elveit, használjunk interfészt, biztosítsuk az egységbezárást, legyen öröklődés, alkalmazzuk a polimorfizmust, legyen szép és elegáns megoldás, legyen a jelölésrendszer UML osztálydiagram. Mindez grafikus asztali Java alkalmazásként valósuljon meg.

A modell csomag (M – Model)

A modellhez 1 interfész és 5 osztály tartozik:

Az AdatInterfesz tárolja a modell számításhoz és megjelenítéshez tartozó konstansait (ezek a szimuláció paraméterei), és metódusfejet nem tartalmaz. A Pont2D osztály egy kétdimenziós pont sémája, valós x és y koordinátapárral, eltol() és túlterhelt tavolsag() metódusokkal. Ennek leszármazottja a Pont3D osztály, amely mindezt három dimenzióban biztosítja, valamint pozícióként és sebességvektorként is használható. Az Egitest osztályból létrehozott objektumnak van mérete, pozíciója, sebessége, színe és tömege. Az interfészt implementálja az Adattar osztály, amelynek egitestLista nevű generikus listája elérhetővé és egységesen kezelhetővé teszi a tervben felsorolt 5 égitestet. A ZIndex osztályú objektumok az égitestek kirajzolásakor szükséges mélységpufferbeli adatot képesek kezelni.

A nézet csomag (V – View)

A nézet 2 osztályból áll:

Az Ablak osztály egy javax.swing.JFrame leszármazott, az alkalmazás teljes grafikus felületét biztosítja, valamint előkészíti az eseménykezelést. Tartalompanelje négy vezérlő nyomógombot tartalmaz és rajta található a rajzpanel objektum, a vaszon. A RajzPanel osztály egy javax.swing.JPanel leszármazott, amely kapcsolatban áll az adattárral, és kezeli a mélységpuffert. Ez felel a szimulált 3D térben lévő objektumok 2D-beli leképezéséért, figyelembe véve a nézőpont elmozdulását is. A rajzolást a felüldefiniált (öröklődés) paintComponent() metódus végzi el.

Az Ablak osztályú objektum elsődleges szerepet tölt be a megjelenítésben, keretbe foglalva a látható komponenseket, vagyis a kezelő nyomógombokat és a modellteret. Az objektum megvalósít egy ActionListener eseménykezelőt, így a program reagálni tud a felhasználó által kiváltott eseményekre. Az ablakobjektum nagyítás és forgatás üzenetek küldésével saját vásznát – és csak azt – frissíti.

A vezérlő csomag (C – Controller)

A vezérlőt 2 osztály valósítja meg:

A Main osztály összefogja a projektet, ez a végrehajtás belépési pontja. Szükség szerint átadja az MVC szerinti objektumok referenciáit egymásnak, ezzel biztosítva a kommunikációt közöttük, valamint el is indítja a szimulációt. A Logika osztály képes az égitestek gyorsulásának és vonzásának kiszámítására, az égitestek mozgatására, továbbá a megjelenítésért felelős komponenst megfelelő időközönként értesíti a képernyő frissítésének szükségességéről, ami az alapbeállítás szerint 30 frissítés másodpercenként.

Naprendszer szimuláció – elméleti háttér

2023. december 28.2023. január 8. Szerző: Friedel Attila

Naprendszer szimulációt terveztünk és valósítottunk meg Java nyelven, amit három részből álló blog bejegyzés sorozatban mutatunk be (ez az 1. rész):

Naprendszer szimuláció 1. rész – elméleti háttér
Naprendszer szimuláció 2. rész – objektumorientált tervezés
Naprendszer szimuláció 3. rész – megvalósítás Java nyelven

A Naprendszer szimuláció elméleti háttere

A Naprendszer szimulációhoz elengedhetetlen, hogy ismerjük a homogén koordinátákat, az elemi műveletek egységes megvalósításához szükséges transzformációs mátrixokat, a tömegvonzás elvét és az implementációhoz szükséges MVC modellt.

Homogén koordináták

Számítógépes algoritmusokkal egyszerű a térbeli transzformáció megvalósítása, ha homogén koordinátákat használunk. Segítségükkel az affin transzformációk egységesen kezelhetők. A cél egy egységes matematikai formalizmus alkalmazása. A pontok az égitestek középpontjait fogják jelölni. Legyen a P pont 3D-beli koordinátái: P=(x, y, z). Szükséges egy konstans érték. Ha w≠0, akkor a P pont koordinátái: P=(w·x, w·y, w·z, w). Ha w=1, akkor a P pont normalizált homogén koordinátái: P=(x, y, z, 1). A pontnégyes kijelölése kölcsönösen egyértelmű.

Transzformációk

Koordináta transzformáció során az ábrázolandó grafikus objektum pontjaihoz (tárgypontokhoz) új koordináta-rendszert rendelünk hozzá. Az objektum nem változik (nem torzul, nem változtatja meg az alakját), csupán a nézőpont változik meg. Például: a koordináta-rendszer eltolása, elforgatása, a koordinátatengelyek felcserélése, tükrözése, és a léptékváltás (nagyítás, kicsinyítés, összenyomás, széthúzás), elforgatjuk az ekliptika síkját a szimulált Naprendszerben.

Pont transzformáció esetén a tárgypontokhoz hozzárendeljük azok egy adott szempont szerinti hasonmását. Például: 3D-s tárgyak leképezése 2D-s képre, objektumok eltolása, forgatása, mozgatása, égitestek mozgatása tömegvonzás alapján. Affin transzformációk (egybevágósági és hasonlósági transzformációk) alkalmazása esetén pont képe pont, szakasz képe szakasz, felület képe felület, valamint metsző térelemek eredeti metszésvonala megegyezik azok leképezett metszésvonalával.

A számítógépes grafika területén az affin transzformációk általános alakja (mátrixosan):

A pont a B=(b_x, b_y, b_z) vektorral eltolható. A pont – a T=(t₁₁, t₁₂, …, t₃₃) mátrixot használva – adott szöggel elforgatható, skálázható, tükrözhető. A számítógépes grafikában ezt a transzformációs mátrixot a homogén koordinátákkal alkalmazva, az összes geometriai transzformáció hatékonyan megvalósítható, visszavezethető mátrixok szorzására. Mindezt saját magunk is implementálhatjuk, de része a DirectX és OpenGL rendering pipeline-jának is.

Más módon is lehetne: egyenes és ehhez tartozó szög párossal is dolgozhatnánk.

A tömegvonzás elve

A tömegvonzás bármely két égitest között meghatározott, függ a gravitációs állandótól és az égitestek tömegétől egyenes arányban, az égitestek (tömeg)középpontjainak távolságától fordított arányban. Ez a Newton szerinti értelmezés, amelynek képlete:

A hatás-ellenhatás törvénye miatt a vonzás – egymás felé való gyorsulás – kölcsönös, a gyorsulás az égitestek tömegével fordítottan arányos, sosem nulla. A Naprendszerben a bolygók a Nap körül keringenek, és a bolygóknak lehetnek holdjaik. Egységesen kezelve: égitestek.

A tömegvonzásnak más elméleti megközelítései is vannak: Einstein gödör-modellje, Kepler törvényei, illetve differenciál-egyenletrendszer, integrálszámítás is használható a közelítő képlet helyett (csak ideális modell esetén pontszerű az égitest és gömbszimmetrikus azok tömegeloszlása), illetve ismeretes többféle értelmezés a rendszer/modell stabilitására: Lagrange pontok, Lyapunov stabilitás.

Az MVC modell

A klasszikus megközelítés szerint a szoftveres alkalmazások három, egymástól jól elkülöníthető szereppel rendelkező egységből állnak: modell (model), nézet (view), vezérlő (controller). A Java nyelv Swing komponensei az MVC architektúra szerint működnek.

A vezérlő reagál az érkező eseményre, hozzáfér a modell adatszerkezeteihez, azaz igénybe veszi a modell szolgáltatásait, valamint frissítheti a nézetet. A nézet a vezérlő frissítési kérésére a közvetlenül megkapott adatok alapján, vagy a modelltől elkért adatok alapján frissíti saját magát. A vezérlő határozza meg az alkalmazás, komponens, program működését. Egy modellt több nézet is használhat. A modell közvetlenül is üzenheti a nézetnek, hogy megváltozott. A nézet adja a látványt, amelyet angolul skin vagy „look and feel”-nek neveznek.