Szakdolgozat. Flóra Filip Mihály. Mérnök-informatikus, Hálózati és webes technológiák szakirány, Nappali tagozat

Átírás

1 Szakdolgozat Flóra Filip Mihály Mérnök-informatikus, Hálózati és webes technológiák szakirány, Nappali tagozat Kecskeméti Főiskola Gépipari és Automatizálási Műszaki Főiskolai Kar Kecskemét 2010

2 Tartalom TARTALOM BEVEZETÉS A feladat alap információi Magyarországi országgyűlési választások FELADATSPECIFIKÁCIÓ A megrendelő elvárásai Saját elvárásaim Felhasznált technológiák MEGVALÓSÍTHATÓSÁGI TANULMÁNY A megfelelő adatforrás Megjelenített adatok Térkép generálás terve Térképkalibrálás Hő térkép megvalósítása TERVEZÉS Az MVC modell Az OVI-tól kapott adatok Életciklus vizsgálat Felhasználói felületek terve Használatba vétel előtti programok felület Háttérműveleteket végző egység felülete Front-end oldali vizualizáció és kezelőfelület Programfunkciók terve Háttérműveletek programfunkciói Térkép kalibráló programterv Tesztelés terve

3 5. KIVITELEZÉS Az elkészített szoftver bemutatása A kivitelezéshez használt szoftverek NetBeans PHP IDE: XAMPP: ImageMagick: Könyvtárszerkezet Térkép kalibráló könyvtárszerkezete Adatfeldolgozás könyvtárszerkezete Adatok megjelenítésének könyvtárszerkezete TESZTELÉS FELHASZNÁLÓI ÚTMUTATÓ Térkép kalibráló használata Adatmegjelenés használata Adatfeldolgozás használata ÖSSZEGZÉS...61 MELLÉKLETEK

4 1. Bevezetés Az internet korszakában az online hírforrások egyre nagyobb szerepet kapnak a tömeg hétköznapi tájékozódásában. Számos előnye közül külön megemlíteném a gyorsaságát, és folyamatos naprakészségét. A Tv, rádió és egyéb hagyományosnak mondható médiával ellentétben, az interneten akár percenként lehet frissíteni és publikálni a fontosabb fejleményeket, és ehhez nincs szükség költséges sugárzási időre vagy emberi erőforrásra. Az országos választások alkalmával az emberek mindig különösen nagy érdeklődéssel fordulnak a különféle online hírportálok felé, hogy megtudják a szavazás jelenlegi állapotát. A 2010-es Országgyűlési választások napján (április 11. vasárnap) és másnapján országos történelmi látogatottsági rekordok születtek. A hétvégi látogatók száma vasárnap estére meghaladta a 3 milliót, majd másnap egy ezt is meghaladó 3.7 milliós látogatottságot mért a Médián webaudit [1]. Ennek köszönhetően a nagy látogatottságú hírportáloknál nagy kereslet keletkezik, a mindig aktuális adatokkal rendelkező alkalmazások iránt. Ezeknek egyik speciális tulajdonsága, hogy egyedi módon képes az adatokat megjeleníteni. Egy ilyen program célja, hogy automatikusan jusson hozzá, az Országos Választási Iroda által közzétett, a legfrissebb részvételi adatokhoz és választási eredményekhez. Elvárás az alkalmazással szemben, hogy a központilag módosított nyers adatokat, az üzemeltető személy beavatkozása nélkül, tudja feldolgozni a lehető leggyorsabb módon. Továbbá legyen képes olyan megjelenést nyújtani a hírportál látogatóinak, ami egyszerűen megérthető. Ehhez a számítógép által könnyen kezelt adatokat rendszereznie kell, és az emberi szem számára is elfogadható módon megjeleníti úgy, hogy ránézésre is leolvashatóak legyenek az értékek. Mivel tanulmányaim során mindig is érdekeltek a nagy és összetett adathalmazok és azok az emberek számára is érthető formára hozása, ezért úgy gondolom ez a szakdolgozati téma az ideális számomra. Biztos vagyok benne, hogy ez a feladat, amely bővelkedik korunk felhasznált technológiáival, kihívás lesz számomra. 3

5 Szakdolgozatom célja tehát, egy olyan alkalmazás elkészítése, amely a 2010-es Országgyűlési választások eredményeit jeleníti meg gyorsan, látványosan és mindenki számára érthető formában A feladat alap információi A program megjelenési helye elsősorban a weboldal, amelyet Kecskemét város kérésére kellett kifejleszteni a Mayoka 2006 Bt. (továbbiakban közvetítő cégként megnevezve) megbízásából. A feladat megoldás alapját a VIP szolgáltatás képezi. Ezt az Országos Választási Iroda (továbbiakban OVI) teszi közzé. Ennek keretei közt a választáson induló szervezeteknek, a médiának és egyéb igénylőknek részvételi adatokat és a szavazatösszesítés eredményeit biztosítja az arra jogosultak számára Magyarországi országgyűlési választások Magyarországon az Alkotmány értelmében törvényhozói hatalom a szabad, általános választásokon megválasztott Országgyűlés kezében van. Szavazni a választás napján reggel 6-tól este 19 óráig lehet. A választás napját megelőző nap 0 órától a szavazás befejezéséig kampánycsend van érvényben. A szavazást az Országos Választási Bizottság (OVB) bonyolítja le és felügyeli. Az első fordulóban minden szavazásra jogosult választó külön szavazólapon egy egyéni képviselőjelöltre és egy megyei listát állító pártra, pártszövetségre vagy szervezetre szavazhat. Az egyéni képviselői helyet az első fordulóban az a jelölt nyeri el, aki megszerzi az érvényes szavazatok legalább 50%-át plusz egy szavazatot (abszolút többség), ha legalább a szavazásra jogosultak fele leadta a voksát. A területi és országos listáról a pártokra leadott szavazatok arányában kerülnek képviselők a Parlamentbe. A kompenzációs lista lényege, hogy a vesztes egyéni jelöltekre leadott "töredék" szavazatok alapján is juttatnak képviselői helyeket az őket indító pártoknak, hogy ellensúlyozzák az egyéni körzetekben esetlegesen létrejövő aránytalanságokat. (A tisztán körzetes parlamenti választások esetén extrém esetben előfordulhatna, hogy például minden választókörzetben az "A" párt jelöltje nyeri a választást 55%-kal, "B" párt mindenhol 45%-ot kapna, ebben az esetben, a parlamentben csak az "A" párt jelöltjei jutának be, ami aránytalan lenne a választói akarattal, hiszen a szavazók majdnem fele a "B" pártot támogatta.) 4

6 A listás választás érvényességéhez szintén minimum 50%-os részvétel szükséges, ha ez megvan, akkor a második fordulóban már nincs listás szavazás. A területi listáról csak azok a pártok jelöltjei juthatnak be az Országgyűlésbe, akik országosan a leadott érvényes listás szavazatok minimum 5%-át megszerezték. A szavazatokat a helyi szavazatszámláló bizottságok számolják össze, az eredményről értesítik a helyi, ők pedig az Országos Választási Bizottságot. 5

7 2. Feladatspecifikáció 2.1. A megrendelő elvárásai A program működése különféle biztonsági, műszaki és funkcionális követelményeknek kell megfeleljen. Talán a legfontosabbak ezek közül a megvalósítás biztonságával foglalkozó elvárások, hiszen az alkalmazás egy úgynevezett harmadik féltől származó[2] komponense lenne egy már meglévő és működő rendszernek. Ez azt jelenti, hogy a felhasználó weboldalt nem érheti semmilyen támadás illetve kár a komponens használatából adódóan. Minden elemét úgy kell megtervezni, hogy egy esetleges nem kívánatos külső beavatkozás hatására se lehessen hozzáférni kritikus jelentőségű fájlokhoz illetve adathoz. Mivel a tervezett programot több weboldalon is meg kell tudni jeleníteni, ezért képesnek kell lennie különböző szerverbeállítások és környezeti változók mellett is futni. Megvalósítását nézve szigorú programozási szabályoknak kell megfeleljen, és a lehető leglazább kapcsolatban kell álljon az azt futtató szerverrel. Ez azt jelenti, hogy minél kisebb mértékben függ az elkészítendő program a szerveren megtalálható beállításoktól, annál rugalmasabb lesz a felhasználhatósága. Mint minden nagy forgalmat lebonyolító weboldalnál, törekedni kell az erőforrások minimális felhasználására. A kritikus időpontok közelében, mint például a szavazás befejezése és az azt követő néhány óra, különösen fontos a kiszolgáló szerver számára, hogy egy felhasználó kiszolgálása a lehető legkisebb sávszélességet és HTML renderelési [3] erőforrást igényeljen. Ugyanis minél nagyobb a szerver terhelése, annál kevesebb felhasználót képes kiszolgálni egy időben, ami bizonyos látogatottságszám esetén túlterheltséghez, illetve szélsőséges esetben teljes leálláshoz vezethet. Mivel a megrendelő honlapok mindegyike már kialakult és alkalmazott arculattal rendelkeznek, ezért kulcsfontosságú az új komponens grafikája. Illeszkednie kell egy már meglévő képi világhoz, hogy az oldalt látogató személynek fel se tűnjön, hogy az egyik rész nem a weboldalhoz tartozik. Ez egy nagyon fontos lélektani hatás, mivel így 6

8 olyan érzése lesz az érdeklődőnek, hogy különleges, személyre szabott szolgáltatást kap, és nem egy tömegesen felhasznált, bárhol megkapható információforrásra bukkant. Az adatok mindig gyors feldolgozása és megjeleníthetősége érdekében szükség van egy olyan adatforrásra, amely lehetővé teszi a teljesen automatizált adatszolgáltatást és folyamatosan képes biztosítani az adatstruktúrák konzekvenciáját. Egyeztetve a közvetítő céggel, sikerült egy olyan hivatalos és megbízható adatforrást biztosítani, amelyet az OVI VIP Szolgáltatás névvel biztosít. Ez a szolgáltatás csak korlátolt nyilvánosságú adatokat szolgáltat választáson induló szervezeteknek, a médiának és egyéb igénylőknek. Erre már alapozhattam az elkészítendő programomat, hiszen ez pont az a szolgáltatás, amelyre szükségem volt a feladat megbízható elvégzésére. A stabil működés nagyon fontos része egy ilyen program működésének, viszont ugyanolyan fontos, hogy a látogató elégedett legyen az adatok megjelenésének funkcionalitását tekintve is. Az a felhasználó, akit nem érdekelnek annyira a választási eredmények, vagy már megnézte őket és most már nem kíváncsi rájuk, ugyanúgy meg kell legyen elégedve az oldal működésével, mint az, akinek még újak az adatok. Ennek biztosítására szükség van arra, hogy lehetőség legyen a vizualizációt elrejteni. Mivel egy országos választás során sok adatot kell megjeleníteni, ezért a különböző diagramok és térképek kitesznek legalább egy teljes képernyőnyi adatot. Azok számára, akiket nem, vagy már nem érdekelnek az adatok, kellemetlen lehet tovább böngészni úgy az oldalt, hogy minden lapbetöltéskor képernyőnyi hosszan le kell görgessenek az aktív tartalomhoz. Ezt kiküszöbölve lehetőséget kell biztosítani mindenki számára, hogy az adatok megjelenését minimalizálja, esetleg teljesen elrejtse. Ehhez hozzátartozik az is, hogy ezt a beállítást a böngésző meg kell jegyezze, hogy lapbetöltéskor ne kelljen mindig elrejtetni az adat megjelenítést. A folyamatos érdeklődők számára, és a szerverterheltség csökkentése érdekében szükség van egy olyan funkcióra, ami lehetővé teszi, hogy ne kelljen mindig frissíteni a weboldalt, ha meg akarjuk nézni, van-e újabb információ. Ennek segítségével a felhasználó oldaláról is automatizálhatjuk az értesítést, így akinél csak meg van nyitva a weboldal, de nincs gép előtt csak néha-néha ránéz az eredményekre, annak se kell beavatkoznia. Ez lehetővé teszi, hogy akár kivetítve a weboldalt egyszerre nagyobb 7

9 nézőközönség értesüljön folyamatosan az eredményekről anélkül, hogy valaki a böngészőben folyamatosan a frissítés gombot kelljen nyomnia. Ezen kívül jó lenne, ha valamilyen szintű interaktivitást is bele kell vinni, amely megnövelné a felhasználói élményt. Kihasználva az internetes technológiákat és hogy minden adatot nem lehet egyszerre olvasható formában megjeleníteni, bele kell építeni egy olyan funkciót is, hogy a felhasználó az őt érdeklő témakörben további információért kutatva böngészhessen az alkalmazáson belül. Viszont nem szabad túlságosan megbonyolítani a számára releváns információ megtalálását, mert ebben az esetben pont az ellenkezőjét érjük el vele. Ezáltal a felhasználóban felmerül a kérdés, Mit tudhatok még meg erről az oldalról?, ami alaposabb átnézésre sarkallja és így jobban elmélyítve benne a tudatot, hol, mit látott. Az interaktivitás nagy előny egy alkalmazás számára, viszont külön oda kell figyelni arra is, hogy a leglényegesebb és legszélesebb körben keresett információk ránézésre leolvashatóak legyenek a grafikonokról és más vizualizációkról. Ezeket látványos formában kell megjeleníteni, ami az oldal betöltődésekor egyből magára vonzza a figyelmet, lehetővé téve a látogató számára, hogy a lehető legkevesebb idővel és fáradtsággal járjon a legfontosabb adatok megtalálása. Így akár nagyobb távolságból nézve is meg tudja állapítani, a szavazás jelenlegi állapotát. Ez például nagy képernyőn kivetítés alkalmával hasznos tud lenni Saját elvárásaim Mint a komponens üzemeltetője, részemről is fontos biztonsági, műszaki és funkcionális követelményeket határoztam meg. A programot teljesen automatizált rendszernek tervezem, ugyanakkor mint mindenhol, itt is felmerülhetnek működés közben különféle bonyodalmak. Ezeket a lehető legnagyobb rugalmassággal kell kezelje a rendszer, mert minden emberi beavatkozás egy gép által futtatott rendszerbe, csak lassítja és bizonytalanná teszi a működést, magasabb kockázatot jelentve egy hiba elkövetésére. Emellett szükség van egy olyan beépített rendszerre, amely az adatforgalom és feldolgozás mindenkori állapotáról részletes információkat szolgáltat, megkönnyítve ez által egy esetleges hiba általi leállás okának megértését. Elvileg a főpróba idején az éles 8

10 rendszerrel megegyező működés lesz, az adatok értékétől eltekintve. Ezzel kiküszöbölhető a hibák nagy része, ám ha mégis előfordul egy, akkor a lehető leggyorsabb módon tudok reagálni és a leghatékonyabban tudom megoldani a problémát. A folyamatos állapot felügyeletet lehetőleg én se végezném végig a számítógép előtt ülve, ezért egy olyan telefonos alkalmazást terveztem, amely WIFI-n keresztül képes az állapotinformációkat a telefonom kijelzőjén megjeleníteni. Mivel ezzel csak a számítógéptől szakadtam volna el, és a telefon kijelzőjét bizonyos időközönként ugyanúgy néznem kellett volna, ezért ezzel a megoldással nem elégedtem meg. Tovább fejlesztve a gondolatot azt találtam ki, hogy minden ellenőrzéskor, hogy van-e frissebb adat a központi szerveren, az adat átmásolásokat és egyéb állapotokhoz egyedi hangüzenetekkel párosítottam. Ezáltal mivel a telefonom mindig a közelemben volt, különösebb odafigyelés nélkül is mindig tudtam, hogy a szerveren futó programom hogy teljesít. Szükség esetén azonnal a gép elé tudtam menni, és hibát javítani. Egy másik biztonsággal kapcsolatos elvárásom az volt, hogy bármi történjen az adatok feldolgozása közben, a jelenleg megjelenő információk mindenképp maradjanak meg. Ezáltal, ha a háttérben hibába is ütközik a feldolgozás, a kliens oldalon akkor is stabilan megjelennek az idáig helyesen feldolgozott értékek. Ez nagymértékben hozzájárul a program stabilitásához, mert ilyenkor csak egy kicsit később jelennek meg az adatok, de legalább a helyes adatok. Műszaki követelmények terén én is komoly elvárásokkal rendelkezek, amelyek tervezés és megvalósítás közben többletmunkával jár, viszont az éles működést sokkal stabilabbá és megbízhatóbbá teszi. Program szerkezetileg könnyen átláthatónak kell legyen. Ez lehetővé teszi a hibaforrás gyors beazonosítását, és szükség esetén könnyű javítását. Későbbi továbbfejlesztés, újrahasznosítás esetleg más programozókkal történő együttműködés céljából is fontos a logikailag is helyes szerkezeti felépítés. Az alkalmazást könnyen kell tudni telepíteni más weboldalakra. Ennek megvalósításához a lehető legkevesebb munkára legyen szükség, és az adott rendszeren ne hagyjon nyomot, illetve könnyen eltávolítható legyen a teljes megjelenítés anélkül, hogy a kliens szerveren bármilyen nyoma is maradna a rendszernek. 9

11 A több helyen való felhasználás miatt fontos még, hogy a program arculatát gyorsan át lehessen színezni. Ezáltal nem számít, milyen designnal rendelkezik a kliens weboldal, a program illeszkedni fog a környezetéhez. Ezt célszerű Image sprite technikával megoldani, mivel ezt egy képszerkesztő programmal könnyen át lehet színezni. Ezáltal nem csak a megjelenést lehet gyorsabban beállítani, de mivel még a http kérések számát is csökkenthetjük, a böngészőnek a sok kis kép helyett csak egy nagyobbat kell letöltsön. Ezáltal megspórolható a képekre adott lekérési idő és erőforrás. Funkcionális szempontból is az átláthatóságot és automatizáltságot tűztem ki célul. A választások napján a látogatók minden adatot a lehető leghamarabb szeretnének megtudni. Ennek lehetővé tételét csak egy automatizált programmal lehet csak megvalósítani. Ezáltal az üzemeltető személynek csak felügyelnie kell a folyamatot, nem neki kell elvégeznie az adatfeltöltést. A személyes adatfeltöltés egy lassú, és magas hiba valószínűséggel rendelkező megoldás lenne Felhasznált technológiák A rendszer bővelkedik a korunk által nyújtott technológiák előnyeivel. Az egész program egy Linux operációs rendszerrel rendelkező Apache szerveren lesz futtatva. Mellette, az adatok feldolgozásának eredményeit egy MySQL adatbázis szerver kezeli és tárolja. A VIP szolgáltatás távoli szerverével SSL biztonsági protokoll szerint kell felépíteni a kapcsolatot. A zip archív állományok átmásolását saját szerverre, azok kicsomagolását, az XML fájlokban tárolt adatstruktúrák szinkronizálását az adatbázissal, és ezen adatok feldolgozását az 5.2-es verziószámú PHP fogja elvégezni. A képek automatikus generálását az ImageMagick nyílt forráskódú programcsomag fogja megvalósítani parancssori utasításokon keresztül, amit kérésemre a közvetítő cég még aznap feltelepített a szerverére. A PHP a feldolgozott adatokat a designnak megfelelő HTML rétegstruktúrában küldi ki a kliens oldalra. Ott a CSS segítségével megfelelő megjelenést adok neki. Javascript és jquery segítségével meg hozzáadom azokat a felhasználónál megvalósítandó funkcionalitást, amelyeket fentebb említettem. Az adatok megfelelő feldolgozásához járul hozzá a VIP szolgáltatáshoz kapott adatstruktúrát bemutató dokumentáció, amely UML segítségével mutatja be az adatok viszonyát egymással. A választási körzetek városainak koordinátáit (100+ db), amelyek alapján el tudom készíteni a hőtérképet és az eredmény térképet, a Google Maps API 10

12 használatával, egy magam megírt segédprogram segítségével tudom felügyelt automatizálással meghatározni. 11

13 3. Megvalósíthatósági tanulmány 3.1. A megfelelő adatforrás A feladat tanulmányozásakor első gondolatom az adatforrást tekintve a weboldalon megtalálható eredmények HTML forrására esett. Tervem az volt, hogy a futtató szerveren távolról töltöm be a részvételi adatokat és eredményeket tartalmazó HTML fájlt. Ezután reguláris kifejezésekkel és egyéb PHP-be beépített string műveletekkel kinyerem az adatokat, amelyeket egy lokális adatbázisban tárolok későbbi felhasználásra. Azonban ez több okból sem bizonyult elfogadható megoldásnak. Elsősorban azért, mert élesben, az eredmények oldalon váratlan változások bármikor bekövetkezhetnek, amely az elkészített rendszer stabilitását és ez által a teljes szolgáltatás megvalósulását veszélyeztette volna, amely nemhogy növelte volna a megrendelők tekintélyét, hanem inkább rontana rajta. Egy ilyen bizonytalan változó pedig nem szerepelhetett a tervezett rendszerben, így más megoldás felé kellett kutassak. Szerencsére a közvetítő céggel egyeztetve hozzáférhettem a már megnevezett OVI által biztosított VIP szolgáltatáshoz, amely megoldotta az előbb említett problémákat. Miután már rendelkeztem megfelelő adatszolgáltatással, a következő feladatom a megjeleníthető adatok lehetőségeinek feltérképezése és azok közül a legtöbbet ígérő kiválasztása volt Megjelenített adatok Az OVI minden adatot rendelkezésemre bocsátott, ami azt jelenti, hogy országos szintű adataim vannak a részvételi adatokról, választókörzetekről, pártokról és jelöltekről. Majd a választási idő leteltével választási eredmények ugyanúgy választókörzetenként, jelöltenként és listánként. Először arra gondoltam, hogy minden megkapott adatot megjelenítek, és készítek egy megye választót egy Magyarország térképpel. Az egyik megyére kattintva a térképen animálódva megjelennek a választási körzetek. Valamelyiket kiválasztva megjelennének a részvételi adatok, valamint a jelöltek adatai és elért százalékai. Viszont 12

14 a pusztán számokból álló nagyméretű adathalmazokat nem túl könnyű hatékonyan megjeleníteni úgy, hogy könnyű legyen őket egymással összehasonlítani. Ezen kívül a sok kattintás szükségességével nem éppen felhasználóbarát alkalmazást sikerült volna készíteni. Nem is beszélve a kikapcsolt vagy Javascriptet egyáltalán nem futtató felhasználók kizárásáról. Mivel az alkalmazást előreláthatólag csak Bács-Kiskun megyében (illetve mindig csak egy megyében) használják, úgy gondoltam, ez elég szűkítő tényező ahhoz, hogy egymás mellett megjelenített, ránézésre összehasonlítható grafikonokban gondolkozhassak. Ez a megoldás már jobban tetszett, hiszen sokkal közelebb áll az elvárt eredményhez. Úgyhogy ezen a szálon gondolkoztam tovább. A feladatot úgy fogalmaztam meg, hogy egy olyan megjelenítés kell, ami Javascript nélkül is képes megjeleníteni a legfontosabb adatokat, ugyanakkor, akinél ez az opció engedélyezve van, annak extra szolgáltatásban legyen része. Kezdett körvonalazódni a feladat megvalósítása. Két fő részre van szükség. Egy táblázatos rész, ahol egymás mellett-alatt megjelennek az adott megyéhez és választókörzethez tartozó adatok grafikonon ábrázolva. Ezáltal biztosítva van a Javascripttel nem rendelkező felhasználók, vagy azok értesítése, akik csak ránézésre szeretnének tájékozódni. A másik rész viszont valami komolyabb Javascriptes alkalmazás formájában terveztem megvalósítani. Ezen a részen nagy mennyiségű adatot kell tudni megjeleníteni, hogy a lehető legtöbb információt lehessen továbbítani a felhasználó számára egy helyen. Mivel ez egy országos esemény a legjobb megoldás mindenféleképp egy térképes alkalmazás megvalósítása. Hogy azok számára is legyen értelme a második résznek, akik különben csak az első részből tudnak informálódni, úgy gondoltam a térképen alapból megjelenhetnének információk. Ide olyan megoldást kellett találjak, amivel hatékonyan tudok megjeleníteni sok ember számára érdekes adatokat, még kliens oldali programnyelv nélkülieknek is Térkép generálás terve Első gondolatom egy térképre rajzolt 3D-s grafikon volt. Tulajdonképpen egy domborzati térkép, csak a magasság értékek helyett a részvételi adatok szerepeltek volna érték meghatározóként. Azonban, miután készítettem egy gyors látványtervet, rájöttem, hogy mivel nagyon sok adat van, ezért ez a megoldás hiába látványos, nehéz értelmezni és megvalósítani. A másik oka, hogy elvetettem ezt az ötletet, az a 13

15 rendelkezésre álló képszerkesztő API fejletlensége. Ugyanis akkor még csak a GD2 könyvtárban gondolkodhattam. Az előbbi ötletet tovább fejlesztve arra gondoltam, hogy a térbeli reprezentáció helyett, ábrázoljuk az adatokat a 2D-s megfelelőjével. A harmadik dimenziót meg meglehet oldani egy síkkal és egy harmadik dimenziót jellemző plusz paraméterrel, mint mondjuk a szín. Ekkor gondoltam arra, hogy a részvételi adatokat hő térképpel lehetne vizualizálni. Az előbbi gondolattól csak egy lépés távolságra van, hiszen ha pontot tudok rendelni egy térképen szereplő városhoz, akkor azt valamilyen algoritmus segítségével be tudom úgy színezni a részvételi adatok alapján, hogy a képpontokat össze is olvasztom, ezáltal létrehozva a hő térkép effektet Térképkalibrálás Első lépésben a térképgeneráláshoz, a designban szereplő grafikán kell tudnom elhelyezni a választókerületek városainak pontjait. Ehhez szükségem van minden város pontos koordinátájára, amit meg szeretnék jeleníteni a térképen. Első körben a következő scriptet használtam a városokat egyesével kikeresve: Az első néhány város koordinátájának megszerzése után, abba is hagytam. Egyszerűen túl sok erőforrást igényelt volna az összes város adatainak megszerzése. Arról nem is beszélve, hogy ez nem egy programozóhoz illő megoldás. Ezért inkább körülnéztem a Google Maps API-jában, és hamarosan be is igazolódott a megérzésem. Megtaláltam a keresett megoldást. Ennek segítségével írtam egy olyan félautomata koordináta meghatározó programot, ami közvetlenül az adatbázisból kérte le a városok neveit. Ez alapján visszakereste a Google Maps segítségével a város koordinátáját és egyből meg is jelenítette egy térképen a várost és a koordináta pontos helyét a városon belül. Erre azért volt szükség, mert először teljesen automatikusra készítettem el a programot, viszonyt bizonyos esetekben nem pontosan a város közepét jelölte meg. Ezt a hibaforrást a designban kapott térkép nem teljesen méretarányos és betájolt állapota okozta. Ezt a problémát oldotta meg a megoldásom. Mivel megjelenítette egy nyíllal a koordináta pontos helyét, ezért ránézésre láttam, hogy pontosan mit jelölne meg a térképen. Ha az a hely nem tetszik, és arrébb szeretném helyezni a város közepét jelentő koordinátát, akkor csak meg kellett fogni a térképet, Fogd és vidd módszerrel odahúzni azt a pontot a térképen a nyíl alá. Minden térkép igazítás hatására a koordináták automatikusan átíródtak a térképen szereplő értékre. Aztán már csak a 14

16 1. ábra. heatmap.php által generált kimenet mentés gombot kellett megnyomni, és a program eltárolta a koordinátákat az adatbázisban, és felajánlotta a következő várost a beállításra. Vagyis legközelebb, ha város koordinátákat kell meghatározni, akkor pár perc alatt beállíthatjuk a megfelelő értékeket. Összességében így is gyorsabban végeztem a feladattal, mintha kézzel kellett volna beállítani őket Hő térkép megvalósítása A következő nagy kihívást a hő térkép generálása okozta. Mivel a szerveren csak GD2 képkezelő osztálykönyvtár van feltelepítve, ezért azzal kezdtem el próbálkozni. A technológia fejlesztésének fázisára a feladatot elemi szintűre egyszerűsítettem, és teszt pontokat határoztam meg. Így biztos lehettem benne, hogy mindig lesznek olyan pontok a generált képen, amelyek össze kell, hogy olvadjanak. Első hő térkép generálásom (heatmap.php) eredményét az 1. ábrán láthatjuk. Működés úgy történik, hogy a meghatározott pontokat felrajzoltattam PHP segítségével egy sima fehér hátterű képre. Minden pont úgy került fel, hogy három részre osztottam a közvetlen környezetét. Először a távolabbi hidegebb képpontok színezésével kezdtem kék színnel, aztán jött a közelebb található zöld színnel jelölt környezet, majd végül a legforróbb amit pirossal jelöltem. A további tervem az volt, hogy ezt a képet elmosva PNG fájlformátumot használva a térkép fölé pozícionálom. Azonban ennek a megvalósításnak több hátránya is akadt. Először is, a kapott eredmény nem lett olyan hő térkép, amelyet elvártam. Két közel levő pont nem olvad össze. A következő próbálkozásom (heatmap2.php) a képeken művelt mátrix műveletek voltak. Reményeim szerint találni fogok egy olyan képmanipuláló mátrixot, amely a képre rajzolt pontokat összeolvasztja. Ezért ugyanúgy meghatároztam teszt pontokat a képen, felrajzoltam őket, és írtam egy függvényt, ami elvégzi a mátrix műveleteket a képen. Aztán összegyűjtöttem az inc/matrix.php fájlba azokat a képmanipuláló mátrixokat, amelyeket a Google-lal való keresésem során találtam. Az eredmények a következők lettek: 15

17 2. ábra. heatmap2.php által generált kimenetek 3. ábra. heatmap3.php által generált kimenet Tovább fejlesztve az ötlete elkészítettem a heatmap3.php fájlt, ami az előzőekre alapozva már egy fokkal jobb eredményt szolgáltatott. A pontok felrajzolása után mátrix műveletek segítségével egyszerűen csak elmostam a képpontokat. Ez már jobb és egyszerűbb megoldásnak tűnt, hiszen itt már a szürkeség értéke alapján egyértelműen hozzá lehet rendelni egy színt a színskáláról. Vagyis ha ezt már beszínezzük, akkor közel elfogadható eredményt kapunk. A következő próbálkozással már el is értem a GD2 könyvtárral elérhető lehető legjobb eredményt. A pontokat felvittem a képre 100%-os átlátszósággal (amit a későbbiekben a látogatottsági érték alapján változtatni lehet). Azokat a pontokat, amelyeket össze akartam olvasztani, vagyis amelyek 10 pixel távolságon belül álltak egymáshoz, még összekötöttem egy vonallal. Az elmosás effektet eztán alkalmaztam a képre. Így az 16

18 összekötött terület úgy hat, mintha a két pont össze lenne olvasztva. Eztán jött rá a képpontok erőssége alapján történő színezés. A lépések így néznek ki: 4. ábra. heatmap4.php által generált kimenet lépései Ez a megoldás a hő térkép megjelenésére már elég elfogadható eredményt ad, viszont egy kép fölé illesztve a foltok elég csúnyán jelennek meg. Olyan megoldásra lenne szükség, ahol a foltokon át lehet látni. Jelen esetben az alattuk megtalálható vonalak nem látszódnak, amit az ábrán is láthatunk. Ha a foltok kis területet fednek le a térképen, akkor még el lehet igazodni rajta, viszont a városok egész Magyarországot lefedik, így a végén csak egy foltokból álló Magyarország formájára hasonlító képet kapnánk, ami nem túl látványos és könnyen érthető. Az egyik megoldás erre a problémára egy képpont összeolvasztó algoritmus lenne, ami a hő térkép és az alatta megtalálható térkép képpontjait a Linear burn algoritmus segítségével a jobb oldali ábra formájára hozza. 5. ábra. "Linear burn" algoritmus használata Az algoritmus használata már jó megjelenést biztosítana a térkép számára, viszont egyetlen térkép generálása ennek használata nélkül is közel 5 percbe telik. Az újabb képfeldolgozási művelet megközelítőleg 10 percbe kerülne, ami a szerver processzor 100%-os terheltsége mellett a többi művelet elvégzését lassítaná le. Rosszabb esetben a weboldal kiszolgálás és az egyéb processzoridőt igénylő fontos háttér műveletek eddig az ideig szünetelnek. Ez a szerverszolgáltatás megbízhatóságát veszélyeztetné. Így tehát az eddig alkalmazott algoritmusnak hiába volt jó kimenete, mivel nem volt hatékony, más megoldást kellett keressek. 17

19 Több képkezelő osztályt, programkönyvtárat és fejlesztői fórumot is tanulmányozva a választásom az ImageMagick-ra [4] esett. Számos kiemelkedően jó képkezelő képessége mellett jelen esetben a gyorsasága miatt választottam. Ez a program csomag thread-safe [5] és a legtöbb belső algoritmusa rendelkezik az OpenMP [6] előnyével, amellyel képes kihasználni a több magos processzorokat. Ezzel jelentősen felgyorsul a képfeldolgozás sebessége és parancssori utasításai segítségével a Linear burn algoritmus is sokkal egyszerűbben megvalósítható. Ennek a bővítménynek a használatával a hő térkép generálás ideje a régi eljárás idejének töredékére csökkent. 18

20 4. Tervezés Az előbbiekben meghatároztam az ügyfél és saját követelményeimet is az elkészítendő programmal kapcsolatosan. Felvázoltam, milyen működés mellett, milyen adatokat szeretnénk megjeleníteni. Ennek gyakorlati megvalósításához többféle szempontból is meg kell tervezni a feladatot a későbbi hatékony implementáció érdekében. Itt meg is említem, hogy minden tervezési fázist legalább két részre osztok fel. Az első részben az üzemeltető részéről használt back-end [7] oldalát tervezem meg, amíg a második részben a mindenki által látogatott front-end [8] megjelenítéssel foglalkozok. Ismerve a követelményeket, legelőször is a program felépítését kell meghatározni. Mivel fontos, hogy a vezérlő parancsok jól el legyenek különítve a megvalósítástól és az egész program laza kapcsolatban kell rendelkezzen a saját megjelenítésével, ezért az MVC modellt fogom alkalmazni Az MVC modell Az MVC [9] (Model-View-Controller), egy gyakran használt program szerkezeti minta. Képes megvalósítani a program logika (Controller), az adatkezelés (Model) és az adatmegjelenítés (View) közötti laza kapcsolatot. Ez azt jelenti, hogy a program logikát csak egy interfész köti össze az adatkezeléssel és a megjelenítéssel. Így a felhasználói felület nem befolyásolja az adatkezelést, és az adatok átszervezhetőek lesznek a felhasználói felület változtatása nélkül. Ha az egyes egységek kapcsolódási felülete megmarad, lehetővé válik ezek független módosítása és könnyű újrafelhasználása. Például, előfordulhat, hogy már meglévő programlogikát és adatkezelést szeretnénk felhasználni egy új feladat megvalósításához. Akkor elég csak a sitebuild-et élesíteni, és az adatfeltöltés sablon rendszerét átalakítani a kívánt megjelenésnek megfelelően. A program logikát nagymértékben meghatározza az az adatbázis, amit az OVI szolgáltat a regisztrált ügyfelei számára. Úgyhogy első lépésben az XML állományok specifikációját kell figyelembe venni Az OVI-tól kapott adatok A táblák diagramjait a helykitöltésük miatt a mellékletek közé tettem. 19

21 Először is a vezérlő adatokat tartalmazó fájl felépítését és lehetséges értékeit kell megérteni. A verzio.xml tartalmazza a rendszerrel kapcsolatos működési adatokat. Ez a tábla nincs kapcsolva másikkal, mivel itt egyszerű információkat adnak át. Ilyen például az állományok legutóbbi készítés ideje, vagy az országos feldolgozottság százalékos értéke. Ezt az időpontot kell folyamatosan figyeltetni, és összehasonlítani a legutoljára mentett adatok idejével. Ha van változás, akkor indulhat a feldolgozás. A következőekben a törzsadatokat mutatom be, amelyeket a választások megkezdése előtt kellett letölteni, mert a későbbiekben ezek nem változtak. Itt, az első fájl, amit fel lehet használni a tervezett programhoz, a terulet.xml. Ez tartalmazza a megyékkel kapcsolatos információkat. Minden megye kapott egy egyedi azonosítót maz névvel jelölve. Tehát normalizált adatbázissal van dolgom, amiben csökkentve van az adat redundancia. Ez a fájl tartalmazza a megyekódhoz tartozó rövidés hosszú megyenevet, régió kódot, a körzetben kiosztható mandátumok számát és hogy az részt vesz e a második fordulóban. Erre a táblára leginkább majd csak a lekérdezések során lesz szükség. A következő fájl az oevk.xml, ami az Országos Egyéni Választó Kerületek (OEVK) adatait tartalmazza. Itt megyénként vannak az OEVK-k felbontva. Minden megyén belül egyedi evk (Egyéni Választó Kerület) azonosítót kapnak és meg van határozva a választó kerületek székhelye is. Az egyes OEVK-kat a megye azonosító és az evk kód alapján lehet beazonosítani. Megtudhatjuk azt is, hogy az egyes városokban milyen és hány darab választó körzet van. A telep.xml fájl segítségével tudjuk meghatározni a megye- és település azonosítóhoz tartozó település nevét, kerületét és a település típusát. Ez a tábla sokat lesz használva, hiszen az adatbázis többi táblájában az adatok ezekhez a sorokhoz kapcsolódnak. Egy sort egyértelműen két mező segítségével lehet beazonosítani. Ez a két mező a maz és a taz. A szavkor.xml segítségével lehet beazonosítani egy adott szavazókört egy településen belül. Itt van eltárolva, hogy melyik megyében, milyen településen az adott egyéni választó körzeten belül milyen sorszámmal és milyen címen található meg egy szavazókör. További információkat is tartalmaz az egyes szavazókörök besorolásáról, típusáról valamint hogy érvényes volt-e az első forduló abban az OEVK-ban/TVK-ban, 20

22 amelyhez tartozik a szavazókör. Ezt azért is fontos, mert a későbbiekben a napközi részvételi adatok meghatározásakor ezek alapján lehet beazonosítani és kiszámolni a térképhez szükséges részvételi arányt. A jlcs.xml a jelölő csoportokat tartalmazza. Minden jelölő csoport kapott egy egyedi azonosítót, amellyel a többi táblán belül hivatkozhatnak a csoportra. Valamint el van tárolva, hogy az adott csoportnak hány tagja van. A független jelöltek 0-s azonosítóval és a jelölőcsoport tagjainak száma is 0. A szervezet.xml az induló szervezeteket tárolja. Minden szervezet egy sorban van tárolva. Szervezetenként megtalálható a teljes és rövid neve, valamint a szervezet egyedi azonosítója, amivel a többi tábla tud a későbbiekben hivatkozni rá. Továbbá tartalmazza a választási bizottság döntését is, ami a nyilvántartásba vételt jelenti. Erre a táblára csak az eredmények feldolgozásakor és megjelenítésekor lesz szükség. Az ejelolt.xml tartalmazza az egyéni jelölteket. Minden jelölthöz tartozik egy megye azonosító és egy választó körzet, amivel be lehet azonosítani, hogy melyik EVK-ban indult. Ez az azonosító azonosítja az egyéni jelöltet a szavazatösszesítési állományokban (szeredmt.xml, szavt.xml, kepv.xml) Természetesen tartalmazza a jelölt vezeték nevét és utónevét és az állító jelölő csoport kódját, amivel a jlcs.xml-re hivatkozik. Ezek mellett az egyik mező tartalmazza, hogy a jelölt indulhat-e a második fordulóban, a szavazólapi sorszámot az 1. és a 2. fordulóban, a választási bizottság döntését a nyilvántartásba vétellel kapcsolatosan és jelölve van, ha a jelölt időközben visszalépett vagy meghalt. A tlista.xml tartalmazza a területi listák rekordjait. Ezek a listák is kaptak egy egyedi azonosítót, amellyel a szavazatösszesítési állományokban (szeredmt.xml, szavt.xml, kepv.xml) lehet hivatkozni a megfelelő sorokra. Bejegyzésenként van adat a lista típusáról (önálló vagy közös), a listaállító jelölő csoportról és ugyanúgy, mint a többi jelöltnél a választási bizottság döntéséről és az esetleges visszalépésről. Ennyi statikus adatra van szükség az adatok feldolgozásához. Ezekkel közvetlenül nem végzek műveleteket, viszont a táblák közötti összefüggések átlátásához és természetesen az eredmények megjelenítéséhez elengedhetetlenek. 21

23 A dinamikus (változó) adatokat két részre lehet osztani. A napközbeni részvételi adatokat tároló táblára és a szavazatösszesítést tartalmazó táblákra. A napközbeni részvételi adatokat a napkozi.xml tartalmazza. Ebben a táblában megtalálhatjuk az eddig feldolgozott minden részvételi adatot a reggel 7:00-stól kezdve 17:30-ig. Az időpontonkénti jelentéseket összesítve is megkapom országos (O), területi választókerületi (M), település szintű (T) és szavazóköri szintű (S). A szavazókörök a korábban tárgyalt maz, taz és sorsz azonosítókkal egyértelműen beazonosíthatóak. Rekordonként megkapom a jogosult választópolgárok számát és a megjelentek számát, ami alapján már én is kiszámíthatnám a százalékos értéket, viszont ezt is megadják két számjegyre kerekítve. Ezt a táblát felhasználva fogom tudni legenerálni a részvételi hő térképet, amelynek megvalósításához először egy segéd táblát kell felvennem, amit a későbbiekben fogok kifejteni. Az adatbázis többi táblája már a szavazatösszesítésről fog információt tartalmazni. Ezeket a táblákat csak a szavazás lezárta után, körülbelül este 7 óra után fogom csak megkapni. Addig nincs is szükség ezeknek a fájloknak a vizsgálatára. Az szeredmf.xml fájl tartalmazza az országos valamint a területi illetve egyéni választókerületi szavazási összesítést. Minden összesítő tétel rendelkezik egy egyedi azonosítóval. Ehhez az azonosítóhoz párosul egy összesítési szint (országos, területi- és egyéni választókerületi, település és szavazóköri szintű elemi adatok). Az sfmaz és sfevk mezőkkel azonosíthatjuk be ezeket választó kerületenként az eredményeket. A valtip mező alapján szűrhetjük attól függően, hogy egyéni választókerületi vagy listás választást szeretnénk lekérdezni. Ez eredm mező alapján tudhatjuk meg, hogy az adott adat érvényes, érvénytelen, érvényes, de eredménytelen az eredmény, érvényes és eredményes vagy nem értékelhető. - A mező a névjegyzék zárásakor a névjegyzékben lévő választópolgárok számát, - B mező a szavazás napján igazolás alapján a névjegyzékbe felvett választópolgárok számát, - C mező a választópolgárok száma a névjegyzékben a szavazás befejezésekor, - D mező a külképviseleti névjegyzékben szereplő választópolgárok számát, - E mező a választópolgárok számát összesen, - G mező a hazai szavazókörökben szavazóként megjelentek számát, 22

24 - H mezőt a szavazásról szóló nyilatkozatok számát, - I mező a szavazóként megjelentek számát, - J mező az urnában lévő szavazólapok száma, - L mező az érvénytelen szavazatok számát, - M mező az érvényes szavazatok számát, - N mező a bizottság által vitatott szavazólapok számát tartalmazza. Ezeken kívül kapok még adatokat a várt adatlapok számáról, a beérkezett adatlapok számáról, a beérkezett jegyzőkönyvek számáról, a feldolgozottsági százalékról, az 1 mandátumhoz szükséges szavazatszámról, a területi listán ki nem osztott mandátumok számáról, 2/3-os határszavazatok számáról és hogy hány szavazattól érvényes a területi forduló. A következő fájl az szeredmt.xml, ami a területi, illetve egyéni választókerületi eredmény tétel adatokat tartalmazza. Mint megszokhattam az előző táblák felépítése alapján, itt is minden tétel egyedi azonosítót kapott. Egy tételt a jlid azonosít be, ami a jelölt, lista jelölésének egyedi azonosítója (ejelolt.eid, tlista.tlid). Ehhez van párosítva a kapott szavazat, egy második fordulóban indulhat jelző, a töredékszavazatok száma, korrigált szavazatok száma, levonandó szavazatok száma, kapott mandátumok száma és egy kaphat-e mandátumot jelző (kaphat, nem kaphat, nem történt mandátumszámítás). A területi mandátumosztással kapcsolatos mezőkben (torsz, korszav, mand, levszav) a mandátumszámítás engedély után szerepelhet értelmezhető adat. Amíg a mandátumszámítás meg nem történik, ezen mezők tartalma 0. A szavf.xml fájl tartalmazza a szavazatösszesítési szavazóköri fej adatokat. Itt is minden rekord kapott egy saját egyedi azonosítót. Rekordonként a következő adatokkal gazdálkodhatok: - Forduló száma, - adatlapról vagy jegyzőkönyvről van-e szó, - egyéni vagy listás választási adat, - megye és település azonosító, amelyek alapján be tudom azonosítani a térképen a helyét, - szavazóköri adat, hogy az adott településen belül melyik szavazókörről van szó, - a névjegyzék zárásakor a névjegyzékben lévő választópolgárok számát, 23

25 - a szavazás napján a névjegyzékbe igazolás alapján felvett választópolgárok számát, - a szavazás befejezésekor a választópolgárok számát a névjegyzékben, - a külképviseleti névjegyzékben szereplő választópolgárok számát, - az összes választásra jogosult polgárok számát, - a valamilyen oknál fogva visszautasított választópolgárok számát, - a hazai szavazókörökben szavazóként megjelentek számát, - a szavazásról szóló nyilatkozatok számát (ez a KÜVI-ben megjelentek száma), - a szavazóként összesen megjelentek számát, - az urnában és az érvényes szavazási iratokban lévő szavazólapok számát, - a szavazónkénti eltérést a megjelentek számától, - és az érvénytelen és érvényes szavazatok számát. A szavt.xml tartalmazza a szavazóköri szavazási tétel adatokat. Ebben a táblában a jelöltek / listák kapott szavazatait találom meg. Ebben a táblában vagy az egyéni jelölésbeli ejelolt.xml ben szereplő, vagy a területi listás tlista.xml fájlban szereplő egyedi azonosító szerepel. Ezenek az adatokon kívül még kaptam két zip-et. Az egyik az emblema.zip, ami a párt emblémákat tartalmazza nagy felbontásban. Vagyis jelen esetben, ha ikonként szeretném használni, akkor le kell kicsinyítsem őket, mert feleslegesen növelik a tárhely adatforgalmát. Mivel nagy látogatottságú oldalakról van szó és a várható látogatók bizonyos időpontokban egyszerre és nagymennyiségben fogják kihasználni a szolgáltatást, ezért szükséges erre is odafigyelni. A másik fájl az arckep.zip, amiben pedig az egyéni jelöltek fényképei vannak, ugyanúgy viszonylag nagy felbontásban. Ezekkel az adatokkal gazdálkodva kellett tudnom megvalósítani a feladatot. Elég összetett és sok adatról van szó. Úgyhogy, mivel minden felhasználónak ugyanazokat az adatokat kell megjeleníteni, ezért nem érdemes hosszú, több soros SQL lekérdezésekbe bonyolódni. Helyette inkább készítettem több segéd táblát, amibe csak azokat az adatokat gyűjtöttem ki a megfelelő táblákat összekapcsolva, amelyekre minden alkalommal szükség lesz. A MySQL nem alkalmas ekkora mennyiségű adatok gyors és folyamatos kezelésére. Arra a PostgreSQL lenne a megfelelő adatbázis kezelő, viszont az erőforrások optimális kihasználása végett abba az esetben is ajánlatos segédtáblákat létrehozni. Ugyanakkor ez a motor jelenleg nem áll rendelkezésre. 24

26 Az első segédtábla, amit létrehoztam, az orsznapkozi volt. Itt a napkozi tábla közel sorát dolgoztattam fel és gyűjtöttem össze, lecsökkentve a rekordok számát közel 1000-re. Ezt úgy sikerült elérjem, hogy városonként számoltam átlagot a szavazóköröket egybegyűjtve a megjelentek százalékos adataiból. Ezeket az adatokat aztán a meghatározott időpontonként összegyűjtöttem. Ezt az ezer sort még könnyedén fel tudja dolgozni a MySQL, még egyidejű nagyobb terhelés mellett is. Ezt a táblát több helyen is felhasználtam. Először is a hő térkép generálásakor. Az oevk táblával összekapcsolva meg tudtam határozni a települések koordinátáit a designban szereplő képekével. Aztán már csak a megadott pozíción kellett elhelyezzek egy pontot a megjelentek százalékával arányos méretben és színnel. A másik felhasználását a táblának a térképen elhelyezett linkek fölé helyezve a kurzort láthatjuk. Ilyenkor ugyanis megjelenik egy kis buborék ablakban az adott településre jellemző részvételi adatok időpontonként összegyűjtve. Pont, amire szükségem volt. A következő, már bonyolultabb segédtábla az egyeni tábla. Ide már a szavazat összesítés utáni eredmény adatok kerültek. Ezt a táblát mindenképpen létre kellett hozni, mivel a megfelelő adatok kinyeréséhez 4 nagy mennyiségű rekordokat tartalmazó táblát kellett volna összekapcsolni. Ezáltal még optimalizált SQL lekérdezés segítségével is több soros köztes lekérdezés bejegyzés jött volna létre, egyetlen felhasználó lekérdezésének kiszolgálására, amit nem lett volna képes kiszolgálni jó minőségben a MySQL szerver. Nem is ilyen jellegű felhasználásra lett tervezve. Ebbe a táblába tehát összegyűjtöttem azokat az adatokat, amelyek az országos eredmény térkép generálásához szükséges volt. Ez azt jelenti, hogy településenként össze kellett gyűjteni: - a jelölteket, - a kapott szavazatok számát, - az összes szavazatok számát, - a szavazatuk százalékát, - a térképen megtalálható koordinátáját, - hogy kapott-e mandátumot, - valamint a jelölő csoport megnevezését és azonosítóját. A tábla alapja az oevk tábla rekordjai. Ezeken végighaladva gyűjtöttem össze a megfelelő táblákból a felsorolt adatokat. Az oevk táblából vettem a település azonosítóját, nevét és koordinátáit. Aztán az szeredmf táblából megszereztem az 25

27 érvényes szavazatok számát és a feldolgozottsági arányt. Az ejelolt táblából párosítani tudtam az oevk-khoz tartozó jelöltek nevét és egyedi azonosítóját. Ez alapján a jelölthöz tudtam kapcsolni egy jelölő csoport megnevezést és azonosítót a jlcs táblából. Ezek után már csak a kapott szavazatok számát kellett párosítsam a jelölthöz, amit pedig a szeredmt táblából tudtam megtenni. A többi adatot már az eddigiek alapján könnyen ki tudtam számítani. Ezeket az adatokat a program futása közben a település gombjára kattintva AJAX segítségével is el kell érjem, vagyis a gyors működés megvalósításához elengedhetetlen egy ilyen tábla létezése. Ez alapján már meg tudom könnyen jeleníteni az adott településhez tartozó jelölteket, eredményeit és színeit. A harmadik segédtábla a _teruleti tábla volt. Ezt a táblát adat megjelenítéskor fogom felhasználni. Mivel 127 sort tartalmaz, ezért ez a tábla ugyancsak alkalmas nagy mennyiségű felhasználók kiszolgálására. Ebből a táblából jelenítem meg az országos és megyei eredmények adatait és a feldolgozottság állapotát. Ebben az esetben is több táblában megtalálható adatokat kellett egy táblába összefoglalni. A tábla alapja az szeredmf tábla, amelyekből csak a megyei és országos adatokat használtam fel a cél eléréséhez. Ebből megyénként megkaptam az eredményes szavazatok számát és a feldolgozottsági arányt. Az ebben a táblában megtalálható sfid összesítő tétel egyedi azonosító mező alapján kapcsoltam hozzá a szeredmt táblában megtalálható jelöltenként kapott szavazatok és mandátumok számát. Ehhez pedig a jelölt egyedi azonosítója alapján fűztem hozzá a jelölő csoport azonosítóját és teljes nevét. A további szükséges adatot pedig a meglévő adatokból ki tudtam számítani egy egyszerű százalékszámítás segítségével Életciklus vizsgálat A következőekben megvizsgálom az adatbázis életciklusát, amelyben táblánként kitérek: - a várható adatmennyiségre, amelyet számmal fogok meghatározni, - az igénybevétel időpontjára, amelyben azokat az időpontokat fogom megnevezni, amikor a tábla különböző terheltségek mellett használva lesz, 26

28 - a terheltség mértékére, amelyet pedig diagramon fogok ábrázolni. Fontos megemlíteni, hogy a terheltség vizsgálat a program szempontjából történik. A vízszintes vonallal jelölt adat a felhasználók látogatásaitól függ. Egyeni: - Várható adatmennyiség: < 1000 rekord - Igénybevétel időpontja(i): 19:00 után közvetlenül - Terheltség: 6. ábra. az "egyeni" tábla várható terheltsége Ejelolt: - Várható adatmennyiség: < 1000 rekord - Igénybevétel időpontja(i): 19:00 után, a szavazóköri eredmények összesítése után, valamint a feldolgozás közben folyamatosan, amint közzéteszik az adatokat, és újra generálom a segéd táblákat. Eredményhirdetés után kis terheltség, mivel csak az AJAX-os tartalom betöltések alkalmával van használva. - Terheltség: csak adatfeldolgozás és segéd táblák generálásakor van használva, ezért a terheltség kisebb, és csak akkor van, ha közzétesznek újabb adatokat. A halványabb kékkel a lehetséges felhasználást jelöltem, attól függően, hogy mikorra várható 100%-os feldolgozottság. 7. ábra. az "ejelolt" tábla várható terheltsége 27

29 Jlcs: - Várható adatmennyiség: < 50 rekord - Igénybevétel időpontja(i): 19:00 után, a szavazóköri eredmények összesítése után, valamint a feldolgozás közben folyamatosan, amint közzéteszik az adatokat, és újra generálom a segéd táblákat. Eredményhirdetés után kis terheltség, mivel csak az AJAX-os tartalom betöltések alkalmával van használva. - Terheltség: AJAX-os eredmény megjelenítéskor, adatfeldolgozás és segéd táblák generálásakor van használva, ezért a terheltség kisebb, és csak akkor van, ha közzétesznek újabb adatokat. A halványabb kékkel a lehetséges felhasználást jelöltem, attól függően, hogy mikorra várható 100%-os feldolgozottság. 8. ábra. az "jlcs" tábla várható terheltsége Napkozi: - Várható adatmennyiség: < rekord - Igénybevétel időpontja(i): reggel 7:00-tól kétóránként tüskeszerű igénybevétel. Azon kívül minimális, mivel csak egy országos összesítést kérdezek le belőle. - Terheltség: a részvételi adatok beérkezésekor nagy terheltség, mivel ebből a táblából hozom létre az orsznapkozi táblát. 28

30 9. ábra. a "napkozi" tábla várható terheltsége Oevk: - Várható adatmennyiség: < 200 rekord - Igénybevétel időpontja(i): ez a tábla sokat van használva. Részt vesz a segéd táblák generálásában is, és a folyamatos adatmegjelenítésben is. Reggel 7:00-tól igénybe van véve egészen addig, amíg megjelennek az adatok a weboldalon. - Terheltség: választás napján reggel 7:00-tól kétóránként kicsit erősebb a terheltség, azon kívül folyamatos. 10. ábra. az "oevk" tábla várható terheltsége Orsznapkozi: - Várható adatmennyiség: < 1100 rekord - Igénybevétel időpontja(i): A választás napján reggel 7:00-tól kétóránként nagyobb igénybe vétel, közben meg folyamatos kérés kiszolgálás a látogatók mennyiségétől függően. - Terheltség: választás napján reggel 7:00-tól kétóránként erősebb terheltség, azon kívül folyamatos egészen az adatok megjelenéséig. 29

31 11. ábra. az "orsznapkozi" tábla várható terheltsége Szeredmf: - Várható adatmennyiség: < 200 rekord - Igénybevétel időpontja(i): 19:00 tól tüskeszerűen azokban az időpontokban, amikor újabb szavazóköri eredményeket tesznek közzé. Közben minimális igénybevétel a felhasználók kiszolgálására. Ez néhány rekord lekérdezést jelent felhasználónként. - Terheltség: választás napján este 19:00-tól folyamatos adat frissítés idejéig erősebb terheltség, azon kívül folyamatos egészen addig amíg megjelenik az oldalon az eredményhirdetés. 12. ábra. a "szeredmf" tábla várható terheltsége Szeredmt: - Várható adatmennyiség: < 1000 rekord - Igénybevétel időpontja(i): 19:00 tól tüskeszerűen azokban az időpontokban, amikor újabb szavazóköri eredményeket tesznek közzé. - Terheltség: választás napján este 19:00-tól folyamatos adat frissítés idejéig erősebb terheltség. 30

32 13. ábra. a "szeredmt" tábla várható terheltsége Telep: - Várható adatmennyiség: < 3500 rekord - Igénybevétel időpontja: erre a táblára csak a térkép kalibráció ideje alatt van szükség. - Terheltség: egy alkalommal minimális. Terulet: - Várható adatmennyiség: < 50 rekord - Igénybevétel időpontja: reggel 7:00 után folyamatosan. - Terheltség: a választás napjától reggel 7:00 után. 14. ábra. a "terulet" tábla várható terheltsége Tlista: - Várható adatmennyiség: < 150 rekord 31

33 - Igénybevétel időpontja(i): a választás napján este 19:00-tól adatfrissítések alkalmával - Terheltség: csak adatfrissítés alkalmával, alacsony terheltség. A világosabb kék tüskék jelölik az esetleges adatfrissítéseket. A tüskék száma a feldolgozás gyorsaságától függ. Minél hamarabb dolgozzák fel a szavazatokat, annál kevesebb frissítésre van szükség. 15. ábra. a "tlista" tábla várható terheltsége Verzio: - Várható adatmennyiség: csak 1 rekord. Nem is lesz több. - Igénybevétel időpontja(i): A választás napján reggel 7:00-tól a közvetlenül a kulcsfontosságú időpontok után az igénybevétel nagyon gyakori, viszont egyre ritkább, ahogy telik az idő. A szavazat összesítés megkezdése után periodikusan van használva. - Terhelés: mivel csak egyetlen egy bejegyzésről van szó, így minimális. A világoskék jelölés azt jelzi, hogy ha nincsenek még friss adatok a szerveren, akkor folyamatosan újra kell próbálkozni, vagyis mindig le kell kérdezni az aktuális verziót. 16. ábra. a "verzio" tábla várható terheltsége 32

34 4.4. Felhasználói felületek terve A programmal kapcsolatosan három féle felhasználói felületet lehet megkülönböztetni: - Használatba vétel előtti programok felülete - Háttérműveleteket végző egység felülete - Front-end oldali vizualizáció és kezelőfelület Használatba vétel előtti programok felület Ebben a részben a működés előkészítéséhez szükséges programok felületéről lesz szó. Ezeknél a különálló programoknál a funkcionális design megvalósítása volt a cél az úgynevezett programozó design. Az első ilyen program a térkép kalibráló. Erre a segédprogramra azért van szükség, hogy ha változik a designon megtalálható térkép mérete, akkor könnyen és gyorsan újra lehessen kalibrálni a települések koordinátáit. Az oevk tábla alapján mindig lekérdez egy település nevet, amit a Google Maps API segítségével meghatároz egy térképen. A bal oldali térképet Fogd és vidd módszerrel mozgatva a középen megtalálható nyíl alá kell mozgatni a kívánt részét a térképnek. A Google Maps-hoz megszokott módon itt is ránagyíthatunk / rákicsinyíthetünk a térképre, valamint a műhold képe alapján is tájékozódhatunk. A piros nyíl alatt található koordináta azonnal megjelenik a halványsárga mezőben, amit a Mentés és megnézem a térképen gombra kattintva azonnal le is ment a rendszer. Újratöltődés után egyből lekérdezi a következő meghatározandó várost és elhelyezi az átszámított koordináta értéket a jobb oldali térképen, amit a designból vágtam ki 1:1-es arányban. Ráillesztettem a Google féle térképet, így egy Hibrid térképet kaptam, ahol halványan látszódnak a nagyobb városoknak a helye a térképen. Erre a térképre ráillesztettem a már meghatározott pontokat, így ellenőrizni tudtam egyből, hogy a megadott koordináta pontosan helyezkedik-e a térképen. A Mentés és következő gombra kattintva lementi a jelenlegi koordinátákat, és egyből betölti a következő települést a térképre. Ezáltal sokkal precízebben és gyorsabban be lehet kalibrálni a térképet, mindenféle erőfeszítés nélkül. 33

35 17. ábra. Térkép kalibráló segédprogram A térkép kalibráló program segítségével el tudtam helyezni minden települést a térképen. Most már a településenkénti részvételi adatokat elkészítő program is megvalósulhatott. A következő segédprogram a hő térkép generáló kimenetét beállító program. Ehhez a programhoz nem készítettem külön kezelő felületet, mivel túl sok és nagyon összetett paraméterei vannak, amelyeket egyszerűbb közvetlenül az algoritmusban beállítani. A fájlt betöltve csak a hő térkép közvetlen kimenetét láthatjuk. 18. ábra. hő térkép kalibráló segédprogram kimenete (véletlenszerű adatokkal feltöltött adatokból generálva) A jelölő csoportok szerinti eredmény térképgeneráláshoz is készült egy különálló segédprogram, aminek segítségével be lehet állítani a megfelelő külalakot. Ebben a 34

36 programban is csak az elkészült képet kapjuk meg a kimenetre. A generálás algoritmusát a legjobban közvetlenül a forráskódban lehet szerkeszteni. Mivel minden lépése kommentezve van, ezért a szerkesztése könnyen megérthető, és módosítható. Ezáltal elég rugalmas megoldást kapunk, tehát nincs értelme külön kezelő felületet készíteni hozzá. A program többi része teljesen automatikus, viszont az üzemeltető mindenképp programozó kell legyen, aki átlátja a rendszer működését, mert az adat forrásban bármikor előfordulhat olyan változás, amire nincs felkészítve a rendszer. A térképen a jelölő csoportok jellemző színei jelennek meg attól függően, hogy melyik településen melyik jelölt győzött. A következő kép egy véletlen szám generátorral feltöltött adathalmazon alapul. 19. ábra. A jelölő csoportok szerinti egyik lehetséges eredmény térkép (véletlen szám generátorral feltöltött adatokkal) Háttérműveleteket végző egység felülete A háttér műveleteket végző felületet csak az üzemeltető fogja használni. Jelen esetben ez azt jelenti, hogy csak én fogom látni a feldolgozás menetéhez kapcsolódó üzeneteket, viszont nekem is magas elvárásaim voltak ezzel a felülettel kapcsolatosan. Először is, az üzenetek egységes formában kell megjelenjenek. Ennek érdekében létrehoztam négy féle üzenet típust, amelyeknél ránézésre meg tudtam állapítani melyik üzenetnek milyen tartalma van. Az első ilyen típus a title üzenet. Ez egy olyan különleges információt tartalmaz, amivel el tudom választani az összetartozó üzeneteket mintegy címet adva nekik. Ez akkor hasznos például, ha elkezdem feldolgozni a napkozi táblát. Ilyenkor a 35

37 feldolgozás kezdetén kiküldök a kimenetre egy ilyen üzenetet, és tudom, hogy ami ezután jön bármilyen bejegyzés, az ehhez fog tartozni. Ez megkönnyíti a tájékozódást később, mikor sok üzenetet kell megjeleníteni. 20. ábra. "title" típusú üzenet A következő üzenet típus a log. Ez egy egyszerű üzenet, ami a program jelenlegi állapotáról szolgáltat információt. Például, ha sikerült csatlakozni a távoli szerverhez, akkor kiküldök egy olyan üzenetet, hogy kapcsolat létrejött az 1. csatornán keresztül. Ezt egyszerűen csak meg kell jeleníteni, ugyanakkor fontos információ, ha hibát kell keresni. 21. ábra. "log" típusú üzenet A harmadik üzenet típus a warn (warning). Erre akkor van szükség, ha figyelmeztetést szeretnék megjeleníteni könnyen, egyszerűen. A warn típusú üzenet nem végzetes hibát jelöl, a program futása nem szakad meg tőle. Ugyanúgy tovább működik a program, csak jelzi, hogy valami nem ment teljesen gördülékenyen. Ez is egy nagyon hasznos üzenet lehet, ha hibakeresésre kerül sor. 22. ábra. "warn" típusú üzenet Az utolsó üzenet típus, aminek használatára remélhetőleg nem fog sorkerülni, az az err (error) üzenet. Ezt már csak kritikus hiba esetén kell használni, ha a program már egyáltalán nem futtatható tovább valamilyen oknál fogva. Például, ha nem sikerült kapcsolódni egyik távoli adatokat szolgáltató szerverhez sem, vagy ha nem sikerült kicsomagolni a zip állományokat, mert mondjuk sérült a fájl. 23. ábra. "err" típusú üzenet Ezeket az üzeneteket a megjelenítő médiától függően kell tudni megjeleníteni. Ez azt jelenti, hogy ahogy a követelmények részben említettem, az adatokat meg kell tudnom 36

38 jeleníteni a monitoron, és a telefon kijelzőjén egyaránt. Ez úgy kell történjen, hogy automatikusan fel kell ismernie a programnak a kimeneti médiát. Úgy terveztem megoldani, hogy egy - a Szoftvertechnológia órán tanult - tervezési mintát alkalmazok. A követelményeket figyelembe véve erre a feladatra az Factory method (Gyártó függvény [10]) minta a legalkalmasabb. A Programtervezési minták könyvből idézve a híres Gang of Four [11] szavait láthatjuk, hogy a feladatra tökéletes megoldást biztosít ez az eljárás: Cél: Felület meghatározása egy objektum létrehozásához, az alosztályokra bízva, melyik osztályt példányosítják. A gyártófüggvények megengedik az alosztályoknak, hogy a példányosítást az alosztályokra ruházzák át. Ennek a mintának az alkalmazása lehetővé teszi továbbá, hogy különböző médiákon különféle állapot jelzési hangokat lehessen lejátszani. Számítógépen futtatva például nincs szükség olyan hangos, és figyelemfelkeltő értékű jelzésre, mint telefonon Front-end oldali vizualizáció és kezelőfelület A követelmények részben meghatározott okok miatt, a front-end oldali megjelenésnek inkább a választással kapcsolatos témájú designnal kell rendelkeznie. Lehetőleg minél egyszerűbb legyen, ne legyen túlzsúfolt, és ránézésre meg lehessen találni a keresett információt rajta. Megvalósítását tekintve (mint utólag kiderült) érdemes az image sprite [12] technikát alkalmazni. Ennek lényege, hogy a http kérések számának csökkentése érdekében a sitebuildben [13] nem ismétlődő elemeket egyetlen képen elhelyezve csökkenthető a képek betöltődési ideje. Ez a linkekre és egyéb hover [14] eseménnyel ellátott elemek működésekor is jobb eredményt ad, hiszen már első letöltődéskor is egyből megjelenik az onmouseover állapot képe, ami egyébként először ürességre váltana, és csak aztán villanna be a kép. Azért is nagyon hasznos technika egy megjelenés felépítésére, mert nem kell minden egyes képnél a böngészőnek egy kérést intéznie a szerver felé, és kivárni a válasz és a kapcsolat felépítése alatt eltelt időt. Ehelyett elég csak egyszer lekérni egy nagyobb képet, amit a kiszolgáló szerver sokkal gyorsabban ki tud szolgálni, mint sok kis képet. Emellett nagy előnye még, hogy ha színt kell módosítani a megjelenésben, akkor azt egy képszerkesztő programmal könnyedén és egyszerre meg 37

39 lehet oldani minden képi elemen. Így sok munkát meg tudunk spórolni, hiszen ha megjelenést szeretnénk változtatni, akkor csak egyetlen egy darab képet kell lecserélni. 24. ábra. Front-end oldali megjelenés "sprite" -ja Két táblázatra van szükség. Egy részvételi adatokat tartalmazó táblára, ami a választás napján folyamatosan megjelenik. A másik tábla az eredményeket kell tartalmazza. Ehhez célszerű két oszlopos formában kialakítani a megjelenítést név diagrampárosítással. Ezen kívül szükség van egy olyan gombra, amire kattintva minimalizálni lehet a választással kapcsolatos adatok megjelenítését. A táblázatok alatt kell két egyforma méretű méretarányos Magyarország térkép, amit bekalibrálva le tudom generálni a korábban bemutatott térképeket. A térkép megjelenítést is úgy kell megvalósítani, hogy egyszerre egy térkép is megjelenhessen, hiszen az eredményeket tartalmazó térkép a nap folyamán még teljesen üres. A térképeken el tudom helyezni a városokat, ezáltal meg tudom valósítani, hogy a városok fölé mozgatva az egeret, további információk jelenjenek meg attól függően, hogy melyik térképről van szó. Tehát szükség van egy kicsi oldalon belüli előugró ablakra, amibe AJAX-szal betöltött információkat tudok megjeleníteni. A napközbeni részvételi adatokat tartalmazó térkép esetében ez azt jelenti, hogy kell egy város nevét tartalmazó cím rész és a különböző időpontokhoz tartozó részvételi százalékok. Ezt a popup -ot is úgy kell megoldani, hogy változó hosszúságú tartalmat lehessen beletenni, vagyis, hogy függőlegesen tudjon nyúlni. Az eredménytérkép esetében pedig azt jelenti, hogy a kattintásra kell előjöjjön, vagyis kell hozzá egy bezárás gomb. Mivel egy településen belül több választókörzet is lehet, és ezeket az adatokat nem lehet egyszerre megjeleníteni, ezért szükség van egy vízszintes scroller -ra (Hogy vízszintesen lehessen görgetni lapokat.). Egy-egy lapon mindig csak egy választókörzet jelöltjei jelennek meg a jelölő csoport logójával, és a kapott szavazatok számával és százalékos adataival. A szavazókörök jelölése mellé tehát kell két lapozást megvalósító nyíl. 38

40 A feladatot megvalósító céggel konzultálva, bemutattam a font-end oldali program megjelenésével kapcsolatos elgondolásaimat, és azt közösen tovább gondolva lehetőséget kaptam, hogy a cég designerével felvegyem a kapcsolatot. Közvetlenül vele egyeztetve megalkottuk a követelményeknek megfelelő designt. 25. ábra. Front-end látványterv 4.5. Programfunkciók terve A programfunkciók tervét is két részre bontva tárgyalom. Először a háttérműveletek elvégzéséhez szükséges megvalósításról írok, aztán pedig a feldolgozott adatok megjelenítéséről lesz szó Háttérműveletek programfunkciói Az MVC modellt alkalmazva, először a controllert mutatom be. A modell ezen részét az index.php valósítja meg. Itt történik az osztályok inicializálása, és itt van leprogramozva a program logika. A fájl legelejére egy programmal kapcsolatos 39

41 komment került, amibe le van írva, hogy kinek készült, milyen célból, mit csinál a program, és mi a program logika. Egy időmérés indítása után betöltöm a beállításokat és a model osztályok betöltése után példányosítom a valasztas_vip_szolg nevű osztályt. Az osztályt úgy valósítottam meg, hogy a betöltött beállításokat paraméterül adva, egyből megvalósítottam a kényes adatok beágyazását (Encapsulation [15]). Ezáltal egyből sikerült elrejtenem a programmal kapcsolatos kényes adatokat (pl. adatbázis kapcsolati adatok). Az első és legtöbbet használt része a programnak, az adatok frissítésével kapcsolatos ellenőrzés része következik. Mivel szerver terheltségi okokból nem jó percenként letölteni a nagy méretű fájlokat, hogy le legyen ellenőrizve, hogy vannak-e már frissebb adatok, ezért biztosítanak a VIP szerver üzemeltetők egy verzio.xml fájlt. Ezt folyamatosan ellenőrizve megtudhatom, hogy át kell-e másolni a fájlokat. A $valasztas model kellfrissites() metodusa boolean értékkel tér vissza, tehát ideális annak eldöntésére, hogy a verzio.xml fájlt frissíteni kell-e a szerveren. Ezt egyszerűen úgy tudja eldönteni, hogy a lastmodify.txt ben eltárolok egy időbélyeget [16], ami az utolso verzio.xml fájl ellenőrzés időpontját tartalmazza. Ha nem kell frissítés, akkor a program működés itt le is kell álljon, és ki kell adja a megjelenítő médiának megfelelő hangjelzést. Ha viszont szükség van frissítésre, akkor át kell másolni a saját szerverre a fájlt, és be is kell tölteni az adatbázisba a benne megtalálható értéket a későbbi feldolgozás megkönnyítése érdekében. Az XML fájlok általános feldolgozási módja minden fájlnál felhasználható: $valasztas->downloadfile("/eles/verzio.xml", "download/verzio.xml"); $valasztas->xmltomysql("download/", "verzio", array("ver", "feldar")); Fájl letöltéskor meg kell adni, hogy melyik fájlt szeretnénk letölteni a VIP szerverről, hogy hova szeretnénk átmásolni a saját szerverünkön belül. Az adatok sokkal jobban kezelhetőek MySQL adatbázist használva, mint fájl alapú adatforrásként, ezért célszerű az XML fájlokat feldolgozva szinkronizálni az adatokat egy adatbázis táblával. Ezt valósítja meg az előbbi példában a 2. sor. Meg kell adni, hogy melyik mappában található meg a feldolgozandó fájl, hogy mi a fájl neve (ami egyben az adatbázis tábla neve is) és hogy milyen mezőket szeretnénk átmásolni a táblába. 40

42 Ha ezek a műveletek sikeresen lefutottak, a checkverzio() metodussal le kell ellenorizni, hogy a verzio.xml fájlban található adat alapján szükség van-e a zip állományok átmásolására, a saját szerverre. Ha nincs szükség másolási művelet elvégzésére, akkor a megfelelő hang értesítés lejátszása után álljon le a program futása. Ha pedig van frissebb adat a távoli szerveren, akkor elő kell készíteni az átmásoláshoz szükséges mappa szerkezetet. A zip fájlokat egy meghatározott mappába töltöm át mindig úgy, hogy azon belül létrehozok egy újabb mappát az adatok másolásának időpontjával. Ezáltal mindig könnyen meg lehet állapítani, hogy mikori a legutoljára feldolgozott adathalmaz. A mappák létrehozása után a config.php fájlban meghatározott fájlokat kell áttölteni a megfelelő mappába az előbb bemutatott módon. Ha minden fájlt sikerült átmásolni, akkor az összeset ki kell tömöríteni. Sikeres kitömörítés után az XML-eket szinkronizálni kell az adatbázis táblákkal. Mivel az adatok ezután már sokkal könnyebben kezelhetőek, így elkezdődhet a feldolgozásuk. Ki kell alakítani a segédtáblákat és le kell generálni a térképeket. A következő műveletekre van szükség: - fel kell tölteni új adatokkal az orsznapkozi táblát a $valasztas->calcorsznapkozi() metódus meghívásával, - a részvételi hő térképet le kell generálni, amit a $valasztas->hotmapreszvetel() metódus valósít meg, - ki kell számolni az országos egyéni jelöltek adatait (feltéve, hogy már elérhetőek). Ezt a $valasztas->egyeni() metódusa végzi el. - ugyancsak, ha már elérhetőek az adatok, ki el kell készíteni a területi listák eredményeit tartalmazó segédtáblát, amit a $valasztas->teruletilista() metódusa old meg. - Ha már vannak megjeleníthető adatok, akkor le kell generálni az eredmény térképet is a $valasztas->hotmappartokv2() metódus meghívásával. A back-end oldal program logikája ennyiből áll. A továbbiakban ezeknek a megvalósítását részletezem. Következzen tehát az MVC modell model részének ismertetése: A program kétféle model osztályt használ fel. Az egyik az adatok médiánként megfelelő megjelenítéséért felelős, a másik pedig az adatok feldolgozásával kapcsolatos konkrét műveleteket végzi el. 41

43 Az adatmegjelenítő osztályokkal kezdem. Mivel ugyanazokat az adatokat kell tudnia megjeleníteni különféle formában, ezért a legcélszerűbb megoldása ennek a Gyártó függvény programtervezési minta alkalmazása. Ennek konkrét megvalósításához szükség van egy message interfészre, amelyhez illeszkednie kell a Gyár osztálynak és a konkrét termék osztályoknak is. A Message osztály (message.factory.php) konstruktorában dől el, hogy milyen megjelenést kell betöltsön a program. Annak megfelelően példányosítja a megfelelő termék osztályt. Jelen esetben két termék osztály van. A message_monitor osztályt kell használni, ha számítógép böngészőt használ az üzemeltető. A message_mobile osztály a mobil telefon böngészőjére optimalizált megjelenést biztosít. Mindkét osztály felépítésileg hasonló (az azonos interface miatt), a megvalósításban viszont különböznek. A felhasználó programozó szempontjából könnyebb így kezelni a megjelenítést, hiszen ez által laza kötésben van a program logikától és a háttérműveletektől. Ha a megfelelő interfészeket megvalósítja egy másik megjelenítő osztály is (akár egy Adapter [17] mintát alkalmazva), akkor a megjelenítés nagyon könnyen megvalósítható bármilyen más eszközön is. Ez, a kezdő programozók számára nem tűnik túl optimális megoldásnak, hiszen bonyolultabb átlátni a program menetét, és a megvalósítás is sokkal több forráskóddal jár. Ezek a problémák viszont eltörpülnek a módszer nyújtotta előnyökhöz képest. Egy komolyabb program esetében már fontosabb átláthatóság, a könnyű hibakezelés és nem utolsó sorban a könnyű bővíthetőség és tovább fejlesztés. Az MVC modellt továbbra is szem előtt tartva, a különböző megjelenítésekhez szükséges sablonokat egy-egy külön template fájlban tároltam. A konkrét termék osztályok konstruktorában a médiának megfelelő template fájlt (base.mobile.tpl vagy base.monitor.tpl) betöltöm, és kinyerem belőle az üzenetek megjelenítésének sablonját. Minden üzenet típus egyedi sablon megjelenéssel rendelkezik, amit ugyanúgy a template fájlban határozok meg. Ezáltal, ha új megjelenésre van szükség, egy designer is képes teljesen új arculatot biztosítani az egész programnak anélkül, hogy értenie kellene a programnyelvhez, amiben meg lett valósítva. 26. ábra. az üzenet típusok megjelenésének sablonjai 42

44 Most, hogy már bemutattam a megvalósítás elvét, lássuk a Message gyár konkrét működését. A controllerben betöltöm, és példányosítom a Message osztályt, ami aztán a konstruktorában a változó tartalma alapján eldönti, hogy melyik konkrét termék osztályt kell felhasználni. Ezt követően a példányosított objektumot saját belső változóba eltárolja. Mivel mindegyik Message osztály megvalósítja ugyanazt az interfacet, ezért a programon belül nem is tudjuk, hogy éppen milyen médiára kerül a kimenet. A Message::log, Message::warn, Message::err és Message::title típusú üzeneteket előbb összegyűjti egy változóba, a megfelelő HTML sablon használatával. Az üzenetek objektumon belül tárolódnak kész HTML formában. Miután a program lefutott, a Message::show() metódus meghívásával küldhetjük ki a kimenetre az eddig összegyűjtött üzeneteket. A másik model, amit a controller működése során felhasznál, az az ogyv.core.php-ben található valasztas_vip_szolg osztály. Ebben vannak a program logikát megvalósító metódusok. Ezt az osztályt a controller tölti be és példányosítja, átadva a konstruktorának a config.php-ben megtalálható beállításokat. A konstruktor ezeket az adatokat lementi a saját private hozzáférési szintű változóba. Innentől a beállításokat csak a valasztas_vip_szolg::conf($key) lekérő segítségével kérdezhetjük le. Az osztály metódusait sorra véve, a connect metódussal kezdem. Ennek a meghívásával hozhatunk létre aktív kapcsolatot a VIP szerverrel, az engedélyezett biztonsági (SSL) csatornák egyikén. Mivel ugyanaz a függvény valósítja meg az összes kapcsolódási módot, ezért egy osztályon belüli változóba el kell tároljam, hogy éppen melyik szerverhez próbálok csatlakozni. Ennek segítségével először lekérdezem a beállításokból a megfelelő host IP címét és port számát, és meg is próbálok csatlakozni hozzá. Ha nem sikerült csatlakozni, akkor kapcsolati azonosítót incrementálni kell, így a legközelebbi csatlakozási kísérlet alkalmával a másik adatforráshoz próbál csatlakozni. Kapcsolódás után a kapcsolati objektumot osztályon belüli változóba tárolja a későbbi felhasználás érdekében. Erre az objektumra fájl letöltéskor és a következő metódusban a kapcsolat lezárásakor szükségünk is lesz. Itt egy egyszerű meg is tudom bontani a kapcsolatot. függvényhívással A következő metódus a downloadfile(), amely első paraméterként a forrás URL-t, második paraméterként pedig a cél URL-t várja. Az üres cél fájl létrehozása után az 43

45 előbb felépített kapcsolatot felhasználva kiküld egy kérést a szerver felé a megfelelő biztonsági header paraméterek beállítása után. 27. ábra. SSL biztonsági kapcsolat felépítése egy távoli fájl elérése céljából A $source_url változó tartalmazza a letölteni kívánt fájl elérhetőségét a VIP szerveren megtalálható root-hoz képest. A $host változóban van a cél szerver IP címe. Az XXX -ekkel jelölt rész pedig a generált felhasználónevet és jelszavat jelenti, felhasznalonev:jelszo formában, base64 es kódolásban. Miután beállítottuk a fejlécet, ki is küldjük a kapcsolati objektumra. A szerverről érkező választ a következő ciklussal olvasom be: Az $sk változó megegyezik a kapcsolati objektummal. Így folyamatosan beolvasva a válasz stringet egy változóba tárolom, és 1000 soronként fájlba írom. Így sokkal gyorsabb a művelet, hiszen nem kell soronként a merevlemezre várni, és a másodperc töredéke ideje alatt folyamatosan újraírni ugyanazt a fájlt. Miután a fájl átjött, a paranccsal lezárom a kapcsolatot. A valasztas_vip_szolg::kellfrissites() metódusa állapítja meg, hogy szükség van-e a verzio.xml fájl ellenörzésére. Ezt úgy oldja meg, hogy a valasztas_vip_szolg::getlastmod() visszatérési értékét (ami a lastmodify.txt fájl tartalma) összehasonlítja a mostani időponttal, és megnézni, hogy a beállításokban meghatározott idő eltelt-e az utolsó ellenőrzés óta. Ha úgy ítéli meg, hogy szükség van ellenőrizni a legfrissebb verziót, akkor a controller miután letöltötte a legfrissebb verzio.xml-t, meghívja a valasztas_vip_szolg::checkverzio() metódust. Ez boolean visszatérési értékkel rendelkezik, ami azt jelenti, hogy TRUE t ad vissza, ha történt változás és FALSEszal, ha nem. Ezt egyszerűen úgy ellenőrzi le, hogy beolvassa a fájl tartalmát, az XML-t átadja az xml2ary függvénynek, ami tömbbé konvertálja azt. Ha ez megvan, akkor csak meg kell nézni, hogy a verzio.xml fájlban található dátummal, létre van-e hozva mappa 44

46 a letöltések mappán belül. Ez alapján dönti el, hogy van-e a szerveren feldolgozatlan adat. A valasztas_vip_szolg::getido() metódus mindig azt határozza meg, hogy a jelenlegi időpont szerint, mikori adatokat kell feldolgoznia a programnak. A valasztas_vip_szolg::unzipall() metódus egy paraméterben kapott mappanév alapján kikeresi az abban található összes zip állományt, és egyenként meghívva az valasztas_vip_szolg::unzipfile() metódust mindegyiket kitömöríti a beállításokban meghatározott helyre. Ez a függvény paraméterként egy forrás mappát, fájlnevet és célmappát kér be. Ezek alapján a PHP-be beépített ZipArchive osztályt használva kicsomagolja az archív állományokat. A következő metódus egy nagyon fontos feladatot lát el, megvalósítása pedig érdekes. A valasztas_vip_szolg::xmltomysql() ről van szó. Paraméterként egy forrás mappát, fájlnevet és azoknak a kulcsoknak a neveit kéri be, amelyeket tárolni szeretnénk az adatbázisban. Adatfelöltés előtt törli az adott tábla tartalmát a redundancia elkerülése érdekében. Mivel egyes XML állományok mérete igen nagy tud lenni ( a napkozi.xml közel 20Mb ), a PHP nem tudja könnyen feldolgozni és egyszerre kezelni a tartalmát. Éppen ezért, feldolgozás előtt létrehozok egy sqlbuffer.csv nevű ideiglenes fájlt. A forrásfájlból folyamatosan beolvasva a sorokat bizonyos számú rekordonként lementi az adatokat CSV formátumban ebbe a fájlba, majd egy importáló paranccsal közvetlenül a MySQL szervernek átadva a fájlt feldolgoztatja vele. 28. ábra. nagyméretű XML állomány optimalizált importálása MySQL adatbázisba Ez a megoldás több szempontból is hatékonyabb, mint a soronkénti feltöltés mysql_query() paranccsal kiadva. A rekordokat nem egyesével kell felvinni az adatbázisba. Ez hiába történne automatizálva, a script által, mivel tízezres nagyságrendben kell gondolkodni, lassú megoldás. A teszt időszak alatt kapott sort tartalmazó XML fájl feldolgozása localhoston (!) is több mint 5 percbe telt. A megoldás másik nagy előnye, hogy nincs szükség folyamatos kommunikációra az Apache szerver és a MySQL szerver között. A másik érdekes kérdés, hogy mennyi az 45

47 optimális rekord szám, amelyet egyszerre kiírva a buffer fájlba és a MySQL-be betöltve, a leggyorsabb az adatfeldolgozás. Ennek meghatározására készítettem egy rövid tanulmányt, amelynek csak az eredményét foglalom bele szakdolgozatomba. Készítettem egy külön fájlba egy scriptet, ami csak ezt az importáló algoritmust tartalmazta. Paraméterként beállítottam, hogy előbb 10 rekordonként történjen az importálás. Az eredmény nem volt túl meggyőző. Az értéket folyamatosan növelve először 100-zal, majd 200, 400, 600, 800 és 1000 rekordonként írtam ki fájlba az importálandó XML tartalmát. Ahogy sejtettem, az eredmény egy haranggörbe lett, az optimális eredmény könnyen meghatározható: 800 rekord / importálás. 29. ábra. az optimális adatimportálás alakulása A model további részei az adatfeldolgozásért felelősek. A következő metódusok végzik el az orsznapkozi, egyeni és a _teruleti nevű segéd táblák feltöltését és a részvételi hő térkép és az eredmény térkép generálását. A valasztas_vip_szolg::calcorsznapkozi() metódusa dolgozza fel a napkozi tábla adatait, és tölti fel az orsznapkozi segédtáblát a megfelelő adatokkal. Lássuk részletesebben ennek működését. Mivel a napkozi tábla nagy mennyiségű adatot tartalmaz, ezért célszerű mindig csak az éppen frissített adatokat hozzáadni a másik táblához. Ezt könnyen meg lehet határozni az ido mezővel. Éppen ezért, minden egyes feldolgozás előtt törölni kell a jelenlegi $this->ido höz tartozó értékeket. Ezt azért fontos megvalósítani, mert ha valamilyen hiba miatt leállna az adatfeldolgozás, akkor a hibaforrást kiküszöbölve és a feldolgozást újra futtatva ne legyen meg a táblában többször ugyanaz az adat. Ezután következhet az adatok feldolgozása. Először is lekérdezi a településeket és a hozzá tartozó maz és taz azonosítókat. Ezek alapján le 46

48 lehet kérdezni a megjelentek százalékát a napkozi táblából. Ezeket az adatokat aztán egyből le is lehet menteni az orsznapkozi táblába. A következő, valasztas_vip_szolg::hotmapreszvetel() metódus a részvételi hő térképet generálja le. Itt egyből fel is használjuk az orsznapkozi tábla adatait. Először is meg kell határozni a megjszaz mező maximális értékét, hogy be lehessen állítani a térkép színskáláját. Ha ez megvan, le kell kérdezni településenként a megjelentek százalékát az orsznapkozi táblából, és az oevk táblát felhasználva létrehozom a táblák közös leképezését. Ez alapján az ideiglenes tábla alapján már meg tudom állapítani, hogy a térkép melyik koordinátájához milyen megjszaz érték tartozik. Ennyi szükséges a feladat megvalósításához. A következő kihívás a térkép színezésének kalibrálása volt. Úgy kellett megoldani, hogy a legvilágosabb ponttól a piros színig mindig jelenjen meg a térképen a színezés. Mivel a színek az adott időponthoz jellemző látogatottsági arányokat tartalmazták szükség volt egy újabb átlagszámításra. A megjszaz százalékos értéket újra kellett számolni a maximális megjelentek számának százalékos értékéhez képest. Ez alapján az adat alapján helyezek el egy százalékos sugarú és szürkeségű kört a térképen. Vagyis minél nagyobb volt valahol a megjelentek százaléka, annál nagyobb és feketébb kört rajzoltatok a térképre. Mivel a blur művelet elvégzése és színezés után minél sötétebb egy pont a térképen, annál melegebb. A teljesen fekete képpont színezés után piros lesz. Ezeket az értékeket jelölő köröket sem egyesével viszem fel a képre, mivel sok fájlművelettel járnának, hanem mivel system utasítást kell mindenképp kiadjak, ezért többet egybefoglalva egyszerre rajzoltatom ki. Ha a képpontok kirajzoltatásával kész van, akkor jön egy 7px-es blur effekt alkalmazása a térképre. Eztán a color_map_vert.jpg színskála alapján a szürke képpontok értéke alapján színezem be. A képpontokat RGB színkódra visszafejtem, ami alapján egy 0 és 255 közötti számot kapok. (A szürkeség érték mindig a három szín azonos számú értéke alapján jön létre). A színskálát úgy hoztam létre, hogy 255px legyen a magassága. Ez alapján a szürkeség érték alapján már könnyen hozzá tudok rendelni minden szürke árnyalathoz a megfelelő színt. Ez a módszer azért is nagyon hatékony, mert ha más színezésre van szükségünk, elég csak a színskála képét lecserélni, és újra generálni a térképet. A színezés után a hő foltok már szépen látszódnak, viszont a térkép körvonalait még rá kell illeszteni erre a képre. Ezt ugyancsak az ImageMagick segítségével oldom meg. A hő foltos képet és az alap térképes képet a beépített lighten 47

49 [18] algoritmussal olvasztom össze. Ezáltal a térkép sötétebb pixelei megjelennek a színes hő foltos képen, ezáltal létrehozva a hő térképet. Az eredmény térkép feldolgozásához a valasztas_vip_szolg::egyeni() metódusát kell meghívnia a controllernek. Ezt a táblát minden egyes alkalommal újra kell számolni, amint van újabb eredmény. Ezért is kell a feldolgozást egy táblaürítés paranccsal kezdeni. Ezután mivel térképen elhelyezhető pontokhoz szeretnénk eredmény értéket eltárolni, ezért le kell kérdezni az összes rekordot az oevk táblából. Ez az alapja aztán az egyeni tábla egy rekordjának. Vagyis ilyenkor már van egy település azonosító, név és a térképen megtalálható koordináta érték. A maz és evk mező értéke alapján le kell kérdezni az érvényes szavazatok számát és a feldolgozottsági arányt a szeredmf táblából. Ugyancsak ezek alapján az adatok alapján le kell kérdezni az összes oevk-hoz tartozó jelölteket. Ezáltal már meglesz az adott koordinátához tartozó összes jelölt az egyeni táblában. Hogy a koordinátához színt lehessen kapcsolni és aztán AJAX kérés esetén popup ablakba meg lehessen nevezni a jelölő csoportot, ezért minden jelölt esetén le kell kérdezni a hozzá tartozó rekordod a jlcs táblából. Most már csak a jelöltekhez tartozó szavazatok számát kell lekérdezni a szeredmt táblából. Megvan minden adat, csak fel kell tölteni az egyeni táblába. A következő képen jól látszik, hogy milyen adatot honnan kellett lekérdezni. 30. ábra. az egyeni tábla feltöltése a különböző táblákból származó adatokkal A valasztas_vip_szolg::teruletilista() metódus a területi listák eredményeit gyűjti össze. Ezt a tábla az országos és megyei eredmények megjelenítésénél lesz használva. Ezt a táblát is üríteni kell minden frissebb adat feldolgozásakor. Ehhez először is le kell 48

50 kérdezni a szeredmf táblából az országos és megyei összesített adatokat. Ezeket a rekordokat a valtip nevű mező tárolja 2-es értékkel. Innen felhasználható az sfid egyedi azonosító, a megyeazonosító, az érvényes szavazatok száma ( m mező) és a feldolgozottság aránya. Az sfid alapján le lehet kérdezni a szeremt táblából a jelölt azonosítóját, kapott szavazatok és mandátumok számát. Ezután csak le kell kérdezni a tlista táblából a jelölt lista nevét, és tölthető is fel a _teruleti tábla. 31. ábra. a _teruleti tábla feltöltése a különböző táblákból származó adatokkal A model utolsó metódusának a feladata az eredmény térkép elkészítése. Ezt a valasztas_vip_szolg::hotmappartokv2() valósítja meg. Először is meg kell határozni, hogy milyen jelölő csoport milyen színnel fog megjelenni a térképen. Ezeket a színeket a kapott logókról vettem le és egy jlcs kulccsal ellátott asszociatív tömbben tároltam el a hexadecimális színkódot. Eztán lekérdeztem az összes koordinátát településenként, majd az ezekhez kapcsolódó maximális szavazat százalékot és a jelölő csoport azonosítót az egyeni táblából. Ha ezek megvannak, akkor ha a csoportnak van színkódja meghatározva, akkor az elért szavazat százalék alapján meghatározott sugarú és a jelölő csoporthoz tartozó színű kört rajzol ki a meghatározott koordinátákon. Ha a jelölő csoporthoz nem párosítható szín, akkor szürke kört fog kirajzolni. A pontokat itt sem egyesével rajzoltatom fel a képre, hanem csoportosan. A körök felrajzoltatása után rá kell illeszteni a képet az alap térképre a színes köröket az ImageMagic darken, a szürke köröket pedig multiply kép illesztési algoritmusát használva. Véletlen adatokból generálva a képet a következő kimenetet kaptam: 49

51 32. ábra. eredmény térkép lehetséges megjelenése (véletlen adatokból készítve) Térkép kalibráló programterv Ez egy különálló program, amit új designban szereplő térkép kalibrálására lehet használni. Google Maps API segítségével működik. Kliens oldali script (Javascript): A load() függvényt a böngésző automatikusan lefuttatja, ha a weboldal betöltődött. A böngésző kompatibilitás ellenőrzése után példányosítok egy GMap2 osztályt paraméterként a map azonosítóval ellátott réteg objektumát adom át. Kétféle vezérlőt párosítok hozzá. A baloldalon megtalálható nagyítókat és mozgatáshoz szükséges nyilakat, és a Térkép, Műhold, Hibrid gombokat. A térképen beállítom, hogy indulásként Magyarország közepét jelölje, és el is helyezet ott egy GMarker-t. Ez, a mindig középen maradó nyíl. A térkép dragend eseményére feliratkoztatok egy névtelen függvényt, ami majd a mozgatás befejeztével lekérdezi a térkép közepén megtalálható nyíl koordinátáját és egyből meg is jeleníti a térkép fölött, és eltárolja egy rejtett beviteli mezőben. Ezáltal az űrlapot elküldve megkapom szerver oldalon a pontos koordinátákat. A showaddress() függvény paraméterként a például a Magyarország, Kecskemét értéket kapja meg. Ez alapján a geocoder objektumot felhasználva a Google segítségével vissza tudom keresni a településhez tartozó szélességi és hosszúsági koordinátákat, és be is állítom a térkép közepére. A body részben egy form található, amelyben a következő mezők vannak: - szekh: rejtett típusú beviteli mező, ahova a település neve kerül. 50

52 - szelessegi: rejtett típusú beviteli mező, ahova a Javascript betölti a térkép közepén megtalálható szélességi koordináta értékét - hosszusagi: rejtett típusú beviteli mező, ahova a Javascript betölti a térkép közepén megtalálható hosszúsági koordináta értékét - address: szöveg típusú beviteli mező ahova a visszakereséshez szükséges formátumban található meg a településnév (Magyarország, [településnév]) - jumptonext: submit típusú gomb, amelyre kattintva elküldi a szerverre a form tartalmát - [név nélküli submit gomb]: ez azért kell, hogy meg lehessen nézni a település jelölését a jobb oldali térképen, és szükség esetén még lehessen rajta módosítani. Ilyenkor ugyanazt a település tölti be újra, és nem ugrik egyből a következőre. Ez alatt található meg a szélességi és hosszúsági koordinátákat tartalmazó táblázat. Itt a lat és lng azonosítóval ellátott táblázat mezők fognak változni. Ez csak a felhasználó számára hasznos, hogy látja, hogy változott a koordináta a térkép pozíciójának a mozgatására. Bal oldalt a Google térképet tartalmazó réteg van, jobb oldalt pedig a saját hibrid térkép, amire kell kalibrálni a koordinátákat. Ezen a térképen jelölve is vannak az eddig beállított koordináták. Itt lehet megnézni, hogy mennyire pontos a koordináta helye. 33. ábra. térkép kalibráló ellenőrző térképe. A képen egy kalibrálás közbeni állapot látható Tesztelés terve A teljes folyamatot csak a választások előtti hét péntekén tudtam csak tesztelni. Ugyanis az éles adatszolgáltatáson kívül, csak ezen az egy napon biztosítják a választási 51

53 szerverhez való kapcsolódást. A controller működése és az adatok másolásával kapcsolatos eljárások csak a tesztnapon tesztelhetőek. Eddig a napig még teszt adatbázis sem áll rendelkezésre, csak az xml fájlok szerkezete és az azokban megtalálható adatok leírása. Így az adatfeldolgozás is addig a napig csak elméleti jelleggel valósítható meg, illetve addig PHP-vel manuálisan feltöltött véletlen számokkal feltöltött adatokkal oldható meg. A fájl kicsomagolás, XML tömbbé alakítása és adatok feltöltése az adatbázisba viszont külön fájlban saját környezetet kialakítva tesztelhetőek. A hő térképkészítést kézzel megadott koordinátákkal kell tesztelni a pontokat úgy megválasztva, hogy legyen a képen ritkán pontozott hely, de legyen sűrű és nagyon sűrű része is. A cél, hogy különböző pont sűrűségek mellett is jó legyen a megjelenés. Az eredmény térkép generálást a térképen elhelyezett véletlenszerű színű és sugarú adatokkal tesztelhető. A térkép kalibrálás is tesztelhető az ország különböző helyén elhelyezkedő kézzel felvitt település neveken keresztül. A kliens oldalon megjelenő eredmény vizualizáció érdemben csak a főpróba után tesztelhető, addig a sitebuild elkészülhet, és tesztelhető a leggyakrabban használt böngészőkben. 52

54 5. Kivitelezés 5.1. Az elkészített szoftver bemutatása A működtetéshez a VIP szerver szolgáltatására van szükség. Ha ez elérhető, akkor az adatfeldolgozas/index.php t kell futtatni, ami aztán elvégzi a szükséges műveleteket. A képernyőn megjelennek a működéssel kapcsolatos információk. Saját magát képes frissíteni, úgyhogy csak az üzeneteket kell megnézni, hogy minden rendben megy-e. Amint a program befejezte az adatfeldolgozást, a weboldalon betöltött (egy egyszerű include() dal) megjelenites/index.php segítségével meg is jelennek a legfrissebb adatok a weboldalon. Ahogy tervezve lett teljesen automatizált rendszer lett, amely többféle megjelenítési felületeken különféle értesítési módokat alkalmazva képes közölni az üzemeltetővel a program aktuális állapotát. Bizonyos szintű hiba megoldási képességgel is el lett látva, ami lehetővé teszi, hogy néhány előre látható esetleges hibát automatikusan kijavítson. Az MVC modell használatával egyes részei - mint például a fájlkezelés, adatimportálás adatbázisba, térképgenerálások, térkép kalibráló - újra felhasználhatóak. A következő választás alkalmával, ha az adatszerkezet nem változik, akkor egy az egyben újra használható. A térkép kalibráló segítségével elegánsan be lehet állítani a település pontjait az aktuális designban szereplő térképen. Használata egyszerű, gyors és könnyen kezelhető. Megjelenésére a minimál design jellemző, amely a lehető legkevesebb vizuális hulladékot tartalmaz, és a használhatóságra van optimalizálva. A program háttérműveleteket végző része megjelenés, működés, sebesség és a szerver terheltség szempontjából is megfelel az elvárásoknak. Az előző pontokban tárgyalt programrészek első próbálkozásra egymagukban 5-10 percet is igénybevettek. Az optimalizált és átgondolt megoldásban viszont a teljes feldolgozási folyamat percek alatt megvalósult. A kliens oldali megjelenés is gyors, mivel csak egyszerű, néhány rekordot érintő lekérdezésekre van szükség egy időben. A felhasznált táblák mérete kevesebb, mint 53

55 1000 sor, vagyis az adatbázis szerver sincs túlterhelve. A sitebuild elkészítésekor az Image Sprite technika lett alkalmazva, aminek segítségével könnyen átszínezhető az egész megjelenés. Ezt élesben a választás napján ki is kellett használni, mivel akkor derült ki, hogy a Gong Rádió is fel szeretné használni a választási részvételi adatok és eredmények megjelenítését A kivitelezéshez használt szoftverek NetBeans PHP IDE: nyílt forráskódú integrált fejlesztői környezet, amely a Java nyelven alapul. A program, programozó barát kezelőfelületének segítségével könnyebben lehet fejleszteni az alkalmazásokat. Beépített Syntax-highlight funkciója van, amelynek segítségével, sokkal átláthatóbbak lesznek a programkódok. A PHP fejlesztői verzióját használtam a program elkészítéséhez, aminek segítségével már a program írásakor láthattam egyes hibákat. JavaDoc stílusú kommentezési rendszert használva a függvény nevek gépelésekor megjelenik egy kis előugró ablak, amiben megjelenik a függvényhez írt dokumentáció. Scope-on belüli változók gépelésekor képes felajánlani azokat a változókat, amelyek az eleje a már begépelt karakterekkel megegyezik. Program sablonokat is be lehet állítani, amelyeket folyamatosan használva rendkívüli mértékben megkönnyíti a gépelést. SVN rendszer kompatibilitása miatt alkalmas közös programozói munkára is. XDebug kiegészítőt telepítve a PHP állományokat is lépésről lépésre tudtam tesztelni, és hiba esetén egyből javítani is XAMPP: ingyenes, könnyen telepíthető web programozói fejlesztő környezet sajátgépre. Ez egy Apache disztribúció, amely beépített MySQL-t, PHP-t és Perl t tartalmaz. Az adatbázis kezelés megkönnyítése érdekében egyből egy PhpMyadmin-t is használhatunk telepítés után. A program alapját ebben a fejlesztői környezetben fejlesztettem ImageMagick: ingyenes programcsomag, amely segítségével képeket lehet létrehozni és módosítani algoritmusok segítségével teljesen automatizáltan. Több 100 féle kép kiterjesztést képes kezelni és rengeteg szerkesztési lehetőséget biztosít. A program kialakításához a sima API-t használtam, nem telepítettem fel hozzá a MagickWand for PHP interface-t. Ez azt 54

56 jelenti, hogy a képmanipuláló parancsokat system() függvény hívásokkal tudtam kiadni a szervernek Könyvtárszerkezet Ezt a pontot három részben fogom bemutatni. Először a térkép kalibráló, aztán az adatfeldolgozás és végül a megjelenítés könyvtár szerkezetét írom le Térkép kalibráló könyvtárszerkezete Images mappa: A térképkalibráláshoz szükséges képeket tartalmazza. Ha idővel kerül rá egy komolyabb design, akkor az ezt felépítő képek ide fognak kerülni. getcoords.php: Ez magában a koordináta beállító program. A programon belüli form is erre a fájlra mutat Adatfeldolgozás könyvtárszerkezete Download mappa: ebbe a mappába kerülnek letöltésre a VIP szerverről átmásolt zip állományok. A fájlok további mappába kerülnek, a letöltés időpontjával megnevezve. A mappa gyökerében található meg a verzio.xml. Generated mappa: ide kerülnek a program által generált hő térképek és eredmény térképek. Images mappa: Az adatfeldolgozás állapotának megjelenítéséhez szükséges képek vannak itt. Ezeken kívül még ide kerültek az egyes állapotokat jelző hangüzenetek is. Include mappa: Idekerültek azok a php fájlok, amelyek a fő program futásához szükségesek. Adatfeldolgozó fájlok, megjelenítéssel foglalkozó fájlok és az eredmény térkép generálását végző fájl. Template mappa: A különböző médiákon történő megjelenések sablonjai és stíluslapjai. Index.php: Mikor élő VIP szerver szolgáltatás van, ezt a fájlt kell futtatni a feldolgozáshoz. Ez a fájl valósítja meg az MVC modellben a Controller szerepét, vagyis itt található meg a program logika. 55

57 Ogyv.core.php: Ez az MVC modellből az adat feldolgozással és térképkészítéssel foglalkozó model rész. Message.factory.php: az MVC modellből az adat megjelenítéssel foglalkozó model rész. Ez a megjelenítő osztály Factory Method-ot megvalósító minta Gyár része. Message.monitor.php: A Factory Method minta konkrét terméke. A monitorra optimalizált megjelenés itt készül el. Message.mobile.php: A Factory Method minta konkrét terméke. A telefonra optimalizált megjelenés itt készül el. Message.config.php: A megjelenéshez szükséges beállítások. Config.php: A program működésével kapcsolatos beállítások. Fájlrendszer elérhetőségek, Host nevek, letöltendő fájlok és működéshez fontos mappanevek meghatározása. Lastmodify.txt: A verzio.xml utolsó ellenőrzésének időpontja. XmlToArray.php: egy XML-t tömbbé alakító osztály Adatok megjelenítésének könyvtárszerkezete Css: A megjelenítéshez szükséges stíluslap fájlok. Images: A megjelenítést felépítő képi állományok. Js: A megjelenés kliens oldali funkcióit tartalmazó Javascript fájl(ok) vannak benne. Index.php: Ebben a fájlban történik az adatok megjelenítése. Ajax.php: Ebben a fájlban történik az AJAX kérések kiszolgálása. 56

58 6. Tesztelés A tesztelést több fázisban tudtam csak elvégezni attól függően, hogy rendelkezésemre álltak-e a tesztelt erőforrások vagy sem. A sitebuild több böngészőben való megjelenését, zip állományok kicsomagolását, adatbázis táblák importálását, adat táblák összekapcsolásával a segédtáblák kialakítását és a térképek generálását teszt adatokkal el tudtam végezni a főpróba előtt is. Ezeket egységekre bontva, kiragadva a végleges környezetükből tudtam tesztelni. A távoli szerverhez való kapcsolódást és a zip állományok átmásolását saját szerverre, valamint az életszerű adatokkal történő tesztelést csak a választások előtti hét péntekén tudtam megoldani. A localhoston fejlesztett programrészeket minden gond nélkül tudtam tesztelni. A tesztelés menete programrészenként kitért a várható hiba lehetőségekre. Térkép kalibráló: a kalibrálás eredményét egyből meg is jelenítettem a Google térkép mellett, úgyhogy a program működésének eredménye egyből tesztelhető volt, és szükség esetén azonnal javítható. A szélességi és hosszúsági körök átszámítása a designban megtalálható pixel alapú koordinátákra nem sikerült azonnal. A designban szereplő vektoros térkép bár pontos volt, mégse egyezett meg teljesen a Google által meghatározott koordinátákkal. Ezt a problémát néhány elforgatási és transzformációs korrekcióval könnyen meg lehetett oldani egy Google által megjelenített Magyarország térképről készített képernyőképpel. A képernyőkép fölé helyezve a designban szereplő térképet már könnyen azonos szinkronizálni lehetett az országhatárt jelölő vonalakat. Adatok megjelenítése a front-enden: Mivel két oszlopos megjelenítés és párospáratlan sor jelölés is szerepelt a designban, ezért mikor az éles adatokkal feltöltött HTML t kellett generálni, akkor az egyik oszlop hosszabb lett, mint a másik. Ezt javítani kellett üres sorok elhelyezésével abban az oszlopban, ahol kevesebb sor található meg, odafigyelve a páros-páratlan sorok színezésére. A választás napján az éles részvételi adatok megjelenítésénél mindig csak a legutóbbi óra látogatottsági térképe jelent meg. Mivel ez a térkép érdekességképpen szolgál, ezért felmerült bennem, hogy ha már megvannak ezek a hő térképek, akkor lehetőséget kéne teremteni a régebbi képek megjelenítésére. Ekkor jött az ötlet, hogy az összes eddig 57

59 elkészült hő térképet pontosan egymás fölé pozícionálva létrehozható egy látványos animáció. Az egymáson elhelyezkedő képek átlátszóságát animálva, változtatva olyan hatás érhető el, mintha a foltok az egyik állapotból átalakulnának egy másikra. Erről készítettem egy kép animációt, amit a következő helyen nézhet meg az érdeklődő: Ezt a jelenséget elérve, az adott időpont oszlopára mozgatva az egér kurzort, az annak megfelelő térkép jelent meg animáció kíséretében. Hő térkép generálás: a hő térkép generáláskor az adatoknak megfelelő sugarú köröket kellett beállítani, amit nem sikerült elsőre eltalálni. Először a térképen megjelenő körök túlságosan kicsik voltak, és mindegyik piros színű volt. Ez egyértelműen nem jó megjelenés, úgyhogy tovább kellett finomítani az algoritmust. A körök méretét megnövelve és nagyobb elmosás effektelve sokkal szebb eredményt kaptam. A piros szín hibáját, a színskála átszínezésével tudtam a megfelelő hőmérsékletre beállítani. Adatfeldolgozás: mivel a VIP szerver kapcsolatot nem tudtam felépíteni a tesztelés napjáig, ezért azt csak leírás alapján tudtam beállítani. Ennek megfelelően nem is sikerült elsőre csatlakozni a szerverhez. Az SSL biztonsági csatornán való kapcsolódáshoz szükséges fejléceket nem sikerült elsőre helyesen beállítani. Az Authorization: részét először kódolatlanul próbáltam felhasználni. A php.net weboldalon talált szabványos fejléc formátumot, felhasználva sikerült megoldani a csatlakozást. A helyes használati szintaktikája a következő: Authorization: Basic base64_encode([felasznalonev]:[jelszo]) Az adatfeldolgozással kapcsolatos következő probléma a zip állományoknál merült fel. A letöltött fájlokat nem lehetett kicsomagolni. Ugyanis a szerverről érkező válasz, egy saját fejléccel rendelkezett, tehát nem csak simán a fájlt küldte át. Keretbe foglalva kaptam meg minden fájlt. Erre a NetBeans hez telepített XDebug szerver oldali hibakereső kiegészítőt használva jöttem rá. A megoldás egyszerű, a válasz első 11 sorát nem kell figyelembe venni, a fájl mentésekor. Ezt megvalósítva már minden gond nélkül lezajlott az összes fájl átmásolása és kitömörítése. A tesztelés ideje alatt és élesben futás közben sem merült fel további probléma. 58

60 7. Felhasználói útmutató A felhasználási útmutatót is három részben mutatom be. Mivel egy automatizált rendszerről van szó, ennek bemutatása nem lesz hosszú. Az volt a cél, hogy ez a rész minél rövidebb legyen Térkép kalibráló használata Ha ettől a rendszertől eltérő helyen szeretnénk felhasználni, akkor használat előtt mindenképp be kell állítani a megfelelő lekérdezéseket. Az images mappában található terkep_hun_reference.jpg fájlt írjuk felül a kalibrálni kívánt térkép képével. Ezen fognak majd megjelenni a beállított pontok. A PHP fájl elején található PHP blokkban található az adatmentés folyamata. Ott az SQL-ben át kell írni a cél helyet és tábla mezőket, amelybe szeretnénk menteni az adatokat. Ez alatt megtalálható egy település lekérdezés. Ezt is át kell írni egy olyan lekérdezésre, amely mindig egy adott település nevet ad vissza. Ha ezeket beállítottuk, akkor kezdődhet a kalibrálás. Használata igen egyszerű. A megadott lekérdezés alapján egyszerre mindig csak egy település név jelenik meg a beviteli mezőben. Alatta megjelenik a Google által meghatározott szélességi és hosszúsági körök. A térképet egérrel mozgatva változtathatjuk a településhez tartozó koordinátát. A Mentés és megnézem a térképen! gombra kattintva az adott koordinátát lementi az adatbázisba, és a designban található térkép bal felső koordinátájához átszámított értékek alapján meg is jeleníti a pontot. A Mentés és következő gombra kattintva pedig lementhetjük az aktuális koordináta értéket, és egyből megjelenik a következő település. Ha a kalibrálást meg szeretnénk szakítani, akkor jegyezzük meg az URL-ben található $_GET[ id ] változó értékét. Erre azért van szükség, mert ha később folytatni szeretnénk a kalibrálást, esetleg egy település helyét újra meg szeretnénk határozni, akkor csak adjuk meg ezt az id-t, és egyből az adott településtől kezdhetjük a beállítást Adatmegjelenés használata mivel csak adatok megjelenéséről van szó, nincs túl sok funkciója. Az egész megjelenítést össze lehet húzni egy sávba az Országgyűlési választások 2010 es felirat sorára kattintva. Ilyenkor az egész választással kapcsolatos adatmegjelenés egy keskeny sáv magas lesz csak. Ezt a beállítást egy böngészőben tárolt süti segítségével 59

61 meg is jegyeztetem, így mikor a felhasználó újra betölti az oldalt, a program emlékezni fog a beállítására. A részvételi adatok oszlopai fölé mozgatva az egér kurzort, az alatta megjelenő hő térképen animálódva megjelenik az adott órához készített térkép. A hő térképen megtalálható településekre kattintva megjelenik az adott település összesített részvételi adatai időpontonként megjelenítve a százalékos adat. Az eredménytérképen található településekre kattintva pedig egy kis oldalon belüli előugró ablakban megjelennek a településhez tartozó választókerület száma (ha több is van) és a kerületek közötti lapozáshoz szükséges vezérlő nyilak. Ezekre a nyilakra kattintva válthatunk a különböző választókerületek jelöltjeinek megjelenítése közt. Választókerületenként megjelenik a listában az összes jelölt neve, képe (ha van), jelölő csoport logója, elért eredmény és hogy kapott-e mandátumot vagy sem Adatfeldolgozás használata ez egy egyedi felhasználásra készített teljesen automatizált feldolgozási rendszer. Ez azt jelenti, hogy csak az adatfeldolgozás mappában található index.php fájlt kell futtatni valamilyen böngészőben. A megjelenő bejegyzések alapján meghatározható a feldolgozás aktuális állapota. Ha egyszer elindítottuk, utána már nincs vele több feladatunk, a program automatikusan frissíti saját magát és hangjelzéssel is értesíti az üzemeltetőjét működéséről. 60

62 8. Összegzés Elkészítése során rengeteg tapasztalattal gazdagodtam. Érdekes volt látni, ahogy egy egyszerűnek tűnő feladatrész megvalósítása során is felmerülnek elsőre megoldhatatlannak tűnő problémák. Ezeken sokat gondolkodva és a lehetséges megoldások után kutatva részletesebb betekintést nyertem a web programozás világába. A választás napján különösen izgultam, hiszen élesben kellett bizonyítson a bevállalt feladat megoldása. Mivel a feladat nem egy sokat használt (és tesztelt) rendszer elkészítése volt, ezért a kezdetekben jelentkező gyermekbetegségektől is tartottam. A kulcsfontosságú időpontokban mindig gép közelben voltam és telefonon keresztül folyamatosan megfigyeltem a folyamatot. A program automatikusan hiba nélkül lefutott, nem volt szükség hibajavításra. Ahogy várható volt, a megrendelő hír portálok látogatottsága aznap jelentősen megugrott. Ezt a terhelést is gond nélkül ki tudták szolgálni a szerverek, és nem történt illetéktelen behatolás. A megvalósított program a követelményeknek megfelelően teljesített. A megrendelő is elégedett volt, amelyet mi sem bizonyít jobban, mint a másnap kapott SMS: Nagyon állat lett a kecskemet.hu! Gratula Ha továbbfejlesztésen kéne gondolkodjak, akkor például az adatkezelés kezelő felületén módosítanék. Készítenék egy újabb termék osztályt a Message.factory számára, amely segítségével CRON-ban is futtathatnám a feldolgozást. Hiba esetén pedig ben értesítene. Ha már kipróbált, és stabil verzióvá nőtte ki magát az alkalmazás, akkor így nem kell mindig megnyitva legyen a böngészőben, hanem a szerver automatikusan futtathatja. A hő térkép generáláson a foltok megjelenésén annyit fejlesztenék, hogy a világosabb színű részeket nagyítanám, mondjuk a kontrasztot variálva. A színskálán a színek kellemesebb árnyalatúvá módosítanám, és a világos (fehér-kék átmenet) részek számára hosszítanám a színátmenetet, hogy a foltoknak finomabb szélei legyenek. Az adatfeldolgozó algoritmuson, ha optimalizálni kéne, akkor a fájlírási és adatbázis importálási paramétereken finomítanék. Külön véve az egyes egységeket a programtól, egységenként lehetne optimalizálni a feladatot, Például az adatbázisba való importálást 61

63 jelenleg 800 parancsonként írom ki fájlba, és töltöm fel adatbázisba. Ez csak megközelítőleg optimális megoldás. Ezt a feladatot egy genetikus-algoritmust vagy az intelligens rendszerek tantárgy keretei között tanult neuronhálót használva tovább lehet optimalizálni, és egy olyan értékre beállítani, amin már tényleg nem lehet tovább gyorsítani. Mivel a feladat sebessége egy haranggörbén meghatározható, egy felezéses algoritmust (Logaritmikus keresés alapja) használva is eljuthatok a keresett számig. Ezt az algoritmust a Problémaosztályok és algoritmusok előadásán ülve, mint rendezett számsor leggyorsabb keresési eljárása alapján ismertem meg. Ezt a gondolatmenetet alakítanám tovább a jelenlegi feladatra. Lényege, hogy eleinte nagy léptekkel el kell végezni a tesztet, megnézni, hogy a csúcspont melyik két nagy szám között van. Aztán a két szám különbségének a felénél újra tesztelni, meghatározni, hogy a töréspont az új szám előtt, vagy után található meg. Aztán az előtte, vagy utána található távolságot újra megfelezve megint futtatni kell egy tesztet az adott számmal. Így tovább haladva egészen addig, amíg meg nem találtuk a feladat optimális megoldását. Ezt az algoritmust fel lehet használni a térképre való körök felrajzolásához is. Kliens oldali megjelenítésen is lehetne még fejleszteni. Például sokkal egyszerűbb lenne a megjelenítést úgy beilleszteni az adott oldalra, hogy csak egy iframe-t kell csak beszúrni az oldalra. Ezt a technikát használja a Google is a térképének betöltésére bármely weboldalra. Különlegesség lehetne még, hogy a megjelenésnek paraméteresen be lehessen állítani a kívánt szélességet. Így olyan weboldalara is beilleszthető lenne, amely keskenyebb. Esetleg ha csak a tartalom részbe szeretnék beilleszteni, akkor ezzel az is megvalósítható lenne. A térkép kalibráló programon fejlesztve, készítenék egy űrlapot, ahova be lehetne írni, hogy milyen tábla milyen mezőiben találhatóak meg a településnevek. Ennek alternatívát nyújtva lehetőséget adnék arra is, hogy egy szöveg beviteli mezőbe (textarea) vesszővel elválasztva lehetne beilleszteni a települések nevét. Ezen kívül meg kéne még tudni adni, hogy melyik táblába és milyen mezőkbe szeretnénk elmenteni a koordinátákat. Itt is lehetőséget adnék a koordináták CSV formátumba való kimentésére, amely ez által bármely másik program könnyen fel tud használni. Ami még ide fontos lenne, az a saját kalibrálandó térkép képének felöltése. Ezeket a fejlesztéseket megvalósítva, ez az alkalmazás már különálló programként is használható lenne. 62

64 Irodalom jegyzék: [1] [2] George T. Heineman, William T. Councill (2001). Component-Based Software Engineering: Putting the Pieces Together. Addison-Wesley Professional [3] Foley; Van Dam; Feiner; Hughes (1990). Computer Graphics: Principles and Practice. Addison Wesley [4] [5] [6] [7], [8] Ka-Ping, Yee. "Definition of a Mediator". Ka-Ping. "In the context of WWW applications, a mediator is a service that functions simultaneously as a server on its front end and as a client on its back end," [9] [10] [Gang of Four] Programtervezési minták: 106. oldal [11] Design Patterns: Elements of Reusable Object-Oriented Software is a software engineering book describing recurring solutions to common problems in software design. The book's authors are Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides with a foreword by Grady Booch. They are often referred to as the Gang of Four, or GoF [12] Brock, Matt. "CSS Sprites: How Yahoo.com and AOL.com Improve Web Performance". Websiteoptimization.com. Retrieved [13] A weboldal készítés azon folyamata, amely során egy látványtervből böngészőben futtatható forráskód készül. 63

65 [14] Ez az esemény akkor váltódik ki, ha az egér kurzort az adott elem fölé visszük. [15] [Gerorge Schlossnagle] PHP fejlesztés felsőfokon. 37. oldal [16] [Gerorge Schlossnagle] PHP fejlesztés felsőfokon oldal [17] [18] 64

66 Mellékletek

67 Adat megjelenítés az országos főpróba adataival 1. sz. melléklet

68 2. sz. melléklet A hő térkép generálás menete

69 Éles indulás, várakozás adatra 3. sz. melléklet

70 kecskemet.hu éles működés 4. sz. melléklet

71 gongradio.hu éles működés 5. sz. melléklet