NÁVRH A REALIZÁCIA WEBOVEJ APLIKÁCIE FINANCOVANIE POLITICKÝCH STRÁN

Transcription

1 Univerzita Komenského v Bratislave Fakulta matematiky, fyziky a informatiky NÁVRH A REALIZÁCIA WEBOVEJ APLIKÁCIE FINANCOVANIE POLITICKÝCH STRÁN Bakalárska práca 2017 Tomáš Sláma

2 Univerzita Komenského v Bratislave Fakulta matematiky, fyziky a informatiky FINANCOVANIE POLITICKÝCH STRÁN Bakalárska práca Študijný program: Aplikovaná informatika Študijný odbor: 2511 Aplikovaná informatika Školiace pracovisko: Katedra aplikovanej informatiky Školiteľ: RNDr. Martin Takáč, PhD. Konzultant: Mgr. Martin Krupa Bratislava, 2017 Tomáš Sláma

3 Čestné vyhlásenie Čestne vyhlasujem, že prácu som vypracoval samostatne s použitím uvedených zdrojov. Bratislava, Tomáš Sláma

4

5

6 Poďakovanie Touto cestou by som chcel poďakovať všetkým, čo mi pomohli s bakalárskou prácou. Moje najväčšie poďakovanie patrí Mgr. Martinovi Krupovi a Šimonovi Zámečníkovi za vedenie, rady a odborné konzultácie, vďaka čomu som v práci neustále napredoval a získal množstvo cenných skúseností. Zároveň moja veľká vďaka patrí môjmu školiteľovi RNDr. Martinovi Takáčovi, PhD, za jeho pomoc pri riešení akademickej časti práce. 1

7 Abstrakt V práci opisujeme nami vytvorené nástroje na vizualizáciu financovania a výdajov politických strán, návrh a implementáciu databázy a popis nami poskytovaného Rest API. Nakoľko sa náš informačný systém skladá z viacerých častí, venujeme sa každej z nich dostatočne podrobne. Nami vytvorené Rest API bude voľne poskytované komukoľvek, kto bude chcieť vytvoriť svoje vlastné vizualizačné nástroje. Vizualizovanie bude prebiehať formou vykresľovania grafov a tabuliek, pričom si používateľ bude môcť vybrať formu reprezentácie údajov. Všetky vizualizované údaje je možné samozrejme exportovať do rôznych grafických formátov, ako napríklad PNG, alebo pripraviť priamo pre tlač. Za správnosť a aktualitu údajov bude v budúcnosti zodpovedať Inštitút pre verejné otázky, pre ktorý je webová aplikácia vyvíjaná. Kľúčové slová: financovanie a výdaje politických strán, vizualizácia 2

8 Abstract We describe in this project tools, which we created for a visualisation of funding and expenses of political parties, scheme and implementation of the database and description of an our own designed Rest api. Since our information system is consisting of many parts, we address to each part of it in detail. Our Rest api will be provided for free to anybody, who would like to create own visualisation tools. The visualisation will be shown in form of drawing the charts and tables, during which time will be user choosing the form of the data representation. All visualised data are possible to export into many graphic formats, for example into PNG, or prepare ready for print. For the correctness and actuality of the data usage will be responsible Inštitút pre verejné otázky, for which this web application was developed. Key words: funding and expenses of political parties, visualisation 3

9 Obsah 1 Úvod 8 Úvod 9 2 Východiská Zmysel a úloha organizácie Inštitútu pre verejné otázky Charakteristika politického systému v SR Členské príspevky Dary Príspevky za hlasy Príspevok na činnosť Príspevok na mandát Prehľad použitých technológií HTML5 a CSS Bootstrap MySQL JSON PHP- Laravel JavaScript Highcharts Podobné portály, inšpirácia Súčasný stav webovej aplikácie Návrh Logika navrhovaného systému

10 3.2 Databázový návrh Tabuľka s názvami politických strán Tabuľka s rokmi Tabuľka s platbami Relačná tabuľka na prepojenie rokov a platieb Tabuľka s výdajmi Návrh Rest api Migrácie Triedy funkcií - Controllery Routovanie Návrh webovej aplikácie Grafický návrh dizajnu Predpokladaná funkcionalita Výber kritérií na vykreslenie grafu Real-time úprava grafu Export údajov Vkladanie nových údajov Typy návštevníkov Mladý človek, vek od rokov Občan vo veku nad 25 rokov Odborná verejnosť (napr. novinár) vo veku nad 25 rokov Zamestnanec organizácie IVO Implementácia Rest api - serverová časť Vytvorenie migrácií Načítanie a uloženie dát do databázy Získavanie a vracanie dát Cesty - routes Webová aplikácia - frontend Filtrovacie nástroje Highcharts a spracovávanie dát

11 5 Používateľský manuál Aktualizácie údajov Výber kritérií na vizualizáciu Exportovanie údajov Záver Možné rozšírenia Literatúra 47 7 Príloha 48 6

12 Zoznam obrázkov 3.1 Ukážka diagramu s návrhom databázy Ukážka štruktúry adresárov v projekte Ukážka súboru routes Ukážka pôvodného grafického návrhu webovej aplikácie Ukážka migračnej triedy Ukážka časti kódu na prechod vstupného súboru Ukážka časti jquery funkcie na získanie označených možností Ukážka časti kódu pre vytvárnie Highcharts grafu Ukážka domovskej obrazovky Rest api Ukážka multiselect boxu Ukážka chceck boxov pre výber typu príspevkov Ukážka chceck boxov pre výber typu výdajov Ukážka jednoduchého select boxu pre výber typu grafu Ukážka stĺpcového grafu Ukážka čiarového grafu a tabuľky Ukážka filtrovania výdajov politických strán Ukážka filtrovania financovania politických strán Ukážka sekundárneho menu vo vizualizácii

13 Kapitola 1 Úvod V našom každodennom živote sa stretávame so situáciami, kedy vznikne nejaký nový problém a na internete hľadáme nové informácie, ktoré nám pomôžu daný problém lepšie pochopiť, prípadne nájsť riešenie. Trend zverejňovania informácií širšej verejnosti každým rokom rastie a ľudia začínajú postupne vyžadovať stále viac a viac informácií. Digitalizácia údajov už prebehla v mnohých odvetviach, ale v oblasti štátnej správy prebieha pomalšie ako v iných odvetviach. Existuje pre to niekoľko dôvodov. Jedným z nich je rozsiahlosť a množstvo údajov ktoré je potrebné spracovať, alebo aj následná finančná náročnosť spracovania toľkého množstva údajov. Oblasť, na ktorú sme sa zamerali, sa týka oblasti financovania politických strán v Slovenskej republike. Ak si bežný občan, resp. volič chcel pozrieť štatistiku financovania nejakej politickej strany alebo výšku príspevkov, nemal veľa možností. Jedinou ľahko dostupnou možnosťou bola brožúra, ktorú vydáva v určitých intervaloch Inštitút pre verejné otázky. Nakoľko úlohou Inštitútu pre verejné otázky je analyzovať spoločenské, politické, ekonomické, zahraničnopolitické, právne, kultúrne a ďalšie otázky verejného záujmu, začali zverejňovať zistené skutočnosti. Ale v tomto bode nastáva problém. Ako najlepšie podať občanom tak komplexné informácie? Keďže brožúra vychádzala len v tlačenej forme, bolo potrebné poskytnúť čitateľovi veľké množstvo informácií, a tu nastával problém, že tabuľky obsahujúce kľúčové informácie sa stali neprehľadné a pre väčšinu občanov poskytovali až priveľa pre nich nezaujímavých informácií. Najlepším riešením problému je poskytnúť občanom bezplatnú webovú aplikáciu, v ktorej si môže vybrať len 8

14 tie údaje, ktoré ho zaujímajú a až tie následne vizualizovať vo forme tabuliek alebo grafov, ktoré sú často oveľa prehľadnejšie ako množstvo čísiel. Nakoľko žiadna podobná aplikácia v Slovenskej republike neexistuje, bude sa jednať o novú, inovatívnu aplikáciu, ktorá by mala pomôcť nielen verejnosti, ale aj odbornej verejnosti, prípadne zahraničným médiám dostať sa k informáciám ohľadom financovania všetkých politických strán v Slovenskej republike od roku

15 Kapitola 2 Východiská Vo východiskovej kapitole si najprv uvedieme niekoľko bližších informácií o Inštitúte pre verejné otázky. Nakoľko na Slovensku zatiaľ žiadna podobná aplikácia neexistuje, nemôžeme čerpať inšpiráciu z už existujúcich riešení. Bude potrebné preto čerpať zo zahraničných portálov. Podobná aplikácia nie je skoro v žiadnej krajine samozrejmosťou. Predpokladáme, že v budúcnosti bude práve naša aplikácia slúžiť ako inšpirácia pre nové a zaujímavé projekty. Samozrejme si zanalyzujeme a porovnáme našu plánovanú funkcionalitu a funkcionalitu už existujúcich zahraničných aplikácií. Kapitola obsahuje tiež popis vybraných technológií, ktoré sme sa rozhodli použiť pri tvorbe. Pri navrhovaní každého systému je potrebné už na začiatku tvorby zvažovať výskyt možných problémov a snažiť sa im v čas predísť. Niektoré problémy si aj podrobnejšie popíšeme. Na záver bude potrebné určite prejsť si aj podmienky a požiadavky hlavného zadávateľa ( Inštitút pre verejné otázky) a zadávajúcej firmy ( ui42) a popísať návrh nášho riešenia. 2.1 Zmysel a úloha organizácie Inštitútu pre verejné otázky Hlavnou úlohou Inštitútu pre verejné otázky (skrátene IVO) je analyzovať spoločenské, politické a zahraničnopolitické, ekonomické, právne, kultúrne a ďalšie otázky verejného záujmu a zverejňovať zistené skutočnosti. Organizácia býva často označovaná ako základňa výskumných a publikačných aktivít, vďaka čomu napomáha k zveľaďovaniu 10

16 odborného potenciálu krajiny. Pre náš projekt bude dôležitá časť aktivít zaoberajúcich sa oblasťou financovania politických strán a upovedomením verejnosti o výške príspevkov pre politické strany, ktoré vo voľbách dosiahli viac ako 3%. 2.2 Charakteristika politického systému v SR Informácie a hodnoty uvádzané v nasledujúcej časti sme čerpali z brožúry Financovanie politických strán [1]. Politický systém Slovenskej republiky sa definuje ako parlamentná forma vlády s trojitou deľbou moci a multi-straníckym systémom. Jediným zákonodarným a ústavodarným orgánom je parlament, ktorý tvorí 150 poslancov volených na obdobie 4 rokov. Poslanci disponujú slobodným poslaneckým mandátom. Vláda je vrcholným orgánom výkonnej moci a za vykonávanie svojej funkcie zodpovedá vládny kabinet a jeho členovia parlamentu, ktorý môže vláde a jej členom kedykoľvek vysloviť nedôveru pomocou získania hlasov nadpolovičnej väčšiny všetkých poslancov (76 zo 150). Každá jedna politická strana potrebuje na vykonávanie svojich povinností finančné prostriedky. Existuje niekoľko spôsobov, ktorými sú politické strany financované. Môžeme ich rozdeliť na dve základné skupiny: Súkromné financovanie Súkromné financovanie môžeme ďalej rozdeliť do ďalších dvoch kategórií, a to na: Členské príspevky Dary Verejné financovanie Verejné financovanie sa delí do troch kategórií, a to na: Príspevok za hlasy Príspevok na činnosť Príspevok na mandát Hlavným a zásadným rozdielom medzi súkromným a verejným finacovaním strany je, že výška finančnej podpory štátom je akoby odrazom verejného záujmu, ktorý vďaka 11

17 svojej činnosti politické strany naplnili. Oproti tomu výška finančného príspevku v súkromnom financovaní v podobe darov je úplne dobrovoľná, ale každý jeden príspevok musí byť zaevidovaný v evidencii darov a príspevkov, ktorú si musí viesť každá politická strana Členské príspevky Nakoľko zákon neobsahuje nijaké ustanovenia týkajúce sa členských príspevkov, jedinou podmienkou je vedenie osobitnej evidencie o prijatých členských príspevkoch vrátane mena a priezviska člena strany a adresy jeho trvalého pobytu, ak jeho členský príspevok presiahol priemernú sumu 830 eur ( pred zavedením eura sumu SK). Úplná výsledná suma členských príspevkov musí byť uvedená vo výročnej správe strany spolu s osobitnou evidenciou [1] Dary Každá politická strana je povinná viesť evidenciu darov, ktorá obsahuje dátum prijatia daru, jeho hodotu a identifikačné údaje darcu alebo zmluvnej strany. Ak hodnota daru presahuje sumu 166 eur, je možné dar prijať len na základe písomnej zmluvy, ktorá obsahuje všetky nevyhnutné údaje o darcovi a dare. Akonáhle hodnota daru presahuje eur, zmluva musí obsahovať okrem predmetu darovania a povinných údajov aj notársky overené podpisy darcu a prijímateľa daru.[1] Aby sa človek mohol stať darcom, musí spĺňať niekoľko podmienok, ako napríklad: darca musí byť občanom Slovenskej republiky musí uviesť svoje identifikačné údaje dary od štátu, rôznych fondov, obcí, neziskových organizácií atď. sú zakázané Príspevky za hlasy Ak politická strana alebo koalícia získala vo voľbách do Národnej rady Slovenskej republiky viac ako 3 % odovzdaných platných hlasov, má nárok na príspevok vo výške 1% priemernej nominálnej mzdy za kalendárny rok pred rokom konania volieb za každý 12

18 jeden získaný hlas. Strana nemá nárok na vyplatenie príspevku, ak nepredložila predbežnú, alebo záverečnú správu o volebných výdavkoch. Vo volebnom období predstavoval štátny príspevok za jeden voličský hlas sumu vo výške 7,86 eur.[1] Príspevok na činnosť Ak politická strana získala nárok na príspevok za hlasy, tak získava nárok aj na príspevok na činnosť. Výška príspevku na činnosť sa rovná výške príspevku za hlasy a následne sa rozdelí na časti podielov. V prvom roku dostáva strana na účet sumu rovnú výške 3 podielov, počas nasledujúcich rokov sa jej vyplácajú sumy vo výške rovnej 12 podielom, a v roku konania volieb strana dostáva zvyšok zo zostávajúcej sumy. V prípade konania predčasných volieb sa výška príspevkov zníži o počet mesiacov zostávajúcich do konca volebného obdobia Príspevok na mandát Aj pri tejto forme príspevku platí, že strana musí odovzdať všetky potrebné dokumenty, aby mala nárok na príspevok. Táto forma príspevku bola zavedená v roku 2000 pri novelizácii zákona o politických stranách. Nárok na príspevok na mandát má každá strana, ktorá sa dostala do Národnej rady SR a celková výška príspevku sa vypočítava ako násobok priemernej nominálnej mzdy v kalendárnom roku pred konaním volieb. Nejedná sa o príspevok samotnému poslancovi, ale o príspevok strane. Výška ročného príspevku za jeden mandát ( za každý 1. až 20. je to 30-násobok priemernej mzdy) bola v rokoch SK, v rokoch to bolo eur a v rokoch eur. Za 21. a každý ďalší mandát sa vypláca 20-násobok priemernej mzdy.[1] Výška ročného príspevku za jeden mandát v rokoch bola SK, v rokoch to bolo eur a v rokoch eur.[1] 2.3 Prehľad použitých technológií Nakoľko sa jedná o rozsiahlejšiu aplikáciu, využívame množstvo aktuálnych programovacích jazykov, frameworkov a technológií. Aplikáciu delíme na dve menšie časti, 13

19 z ktorých sa jedna vykonáva len na serveri a vracia požadované výsledky pre volania funkcií webovej stránky, ktorá je dostupná verejnosti. Ďaľšou pomyselnou časťou by sme mohli označiť databázovú časť HTML5 a CSS3 Na tvorbu základnej štruktúry webovej aplikácie budeme používať značkovací jazyk HTML vo svojej aktuálnej verzii 5. HTML by sme mohli v skratke charakterizovať ako značkovací jazyk, ktorý kladie dôraz hlavne na prezentáciu informácií. Jazyk HTML vo svojej verzii 5 disponuje jednou z nových funcií, ktorá tvorí hlavnú časť nášho projektu, a to technológiou Canvas 2D, ktorá nám umožňuje vykresľovať 2D obrázky pomocou valania JavaScriptových funkcií[9]. Vďaka tomu budeme schopní vizualizovať dáta v podobe grafov priamo pomocou HTML bez potreby ďalších rozšírení. Obsah naformátovaný pomocou jazyka HTML budeme ďalej štýlovať pomocou kaskádových štýlov CSS vo svojej aktuálnej verzii 3[9]. Pomocou CSS budeme tvoriť dizajn webovej aplikácie a jednoduché animácie pre lepšiu interakciu používateľa s aplikáciou Bootstrap Bootstrap[7] môžeme definovať ako voľne stiahnuteľnú sadu nástrojov a funkcií pre tvorbu rozhrania a dizajnu webových aplikácií. Hlavnou výhodou je použitie za účelom tvorby efektívnej a responzívnej webovej aplikácie, ktorá bude mať zjednotený dizajn tlačidiel, formulárov, rozloženie obsahu, navigácie atď. Bootstrap už obsahuje predpripravenú základnú kostru webovej stránky, ktorú je potrebné následne za pomoci jazykov HTML, CSS a JavaScriptu ďalej prispôsobiť. Z Bootstrapu budem predovšetkým využívať časť API pre generovanie a vytváranie selectových boxov a štýlovanie tlačidiel. Na prezentačné účely využijeme aj kostru webovej stránky, nakoľko funkcionalita našej aplikácie bude na stránku ivo.sk implementovaná až neskôr MySQL Webová aplikácia využíva ako úložisko dát databázu, ktorá je teda nevyhnutá pre beh webovej aplikácie. Predpokladáme použitie štandardnej, bežne používanej My- SQL databázy. V prípade potreby je možné aplikovať namiesto MySQL aj PostgreSQL 14

20 databázu. Databázový systém MySQL je relačný typ DBSM (database management system)[4]. Databázu tvorí niekoľko tabuliek pozostávajúcich z riadkov a stĺpcov. Na prístup k dátam budeme využívať dotazy vychádzajúce z programovacieho jazyka SQL, ktorého syntax je mierne prispôsobená potrebám MySQL databázy. Zároveň už teraz predpokladáme použitie PHP frameworku Laravel, ktorý má ešte svoje vlastné databázové volania a funkcie, teda vo väčšine prípadov sa nebude jednať o klasickú SQL syntax JSON JavaScript Object Notation[8], alebo JavaScriptový objektový zápis je spôsob zápisu dát, ktoré bývajú organizované v poliach alebo agregované v objektoch. Hlavnou výhodou JSONu je jeho nezávislosť na platforme, a aj vďaka tomu môžeme predpokladať výstup vždy vo forme reťazca. JSON dáta budú tvoriť jednu z hlavných funkcionalít našej aplikácie PHP- Laravel Hlavná funkčnosť aplikácie na strane servera bude naprogramovaná pomocou využitia jazyka PHP a frameworku Laravel vo svojej aktuálnej verzii 5.3 (pozn., táto verzia bola aktuálna v čase navrhovania a programovania systému). Hlavnou výhodou použitia frameworku je ušetrenie času na programovaní funkcií, ktoré sú už vstavané priamo vo frameworku a aj následná lepšia prehľadnosť a čitateľnosť kódu. Ďalšou z výhod Laravelu je, že databázový controller vracia po vykonanom dopyte automaticky dáta vo formáte JSON ako objekty (vychádzame zo zistení z oficiálneho manuálu a dokumentácie [3]), teda práca s dátami je prehľadnejšia a efektívnejšia. Celá logika frameworku je postavená na princípe Controller-ov a View-ov. View nám umožňuje reprezentovať dáta napríklad vo formáte HTML, v ktorom môžeme predpokladať dáta získané pomocou funkcií môjho controllera. V controlleri spravujeme interakciu medzi vstupom od používateľa a pohľadom (View). Výsledom spracovania dát v controllery môže byť buď vykonanie zmeny v databáze a vrátenie nového pohľadu, alebo len načítanie nového pohľadu bez vačších zmien. V našom prípade nebudeme vracať žiadne pohľady s dátami, ale budeme vracať len JSON dát potom čo si nejaká webová aplikácia po 15

21 zavolaní adresy servera (a funkcie) vypýta konkrétne dáta. V projekte budeme Laravel využívať pri tvorbe Rest API vďaka svojej prepracovanej a jednoduchej správe ciest (routing). Medzi základnú funkcionalitu môžeme zaradiť aj optimalizované sessions a caching [6] JavaScript JavaScript je skriptovací jazyk zameraný najmä na tvorbu webových aplikácií a vykonávanie dynamických funkcií na strane klienta, nie na strane servera. Jeho syntax je založená na jazyku C, ale neexistuje žiadne priame prepojenie s jazykom Java, kvôli čomu nemáme k dispozícii množstvo dátových štruktúr a funkcií, ktorými disponuje Java. Výhodou JavaScriptu oproti PHP je, že sa vykonáva priamo na zariadení používateľa a teda nie je potrebné po vykonaní nejakej činnosti čakať na odpoveď servera[5]. Nakoľko naša aplikácia obsahuje množstvo dynamických prvkov, bude využívaný prevažne pri používaní externých skriptov pre vizualizáciu, alebo pri volaní a spracovávaní údajov získaných zo servera po volaní Rest API. Na vykresľovanie grafov budeme používať API Highcharts, ktoré je tiež naprogramované v JavaScripte Highcharts Vizualizačná knižnica je naprogramovaná v JavaScripte. Knižnica funguje na princípe načítania údajov z databázy, ktoré následne vykreslí na HTML canvas vo forme grafov (predpoklad na základe dokumentácie a materiálov [2]). Používateľ dostane na výber z niekoľkých spôsobov vizualizácie, ako napríklad z rôznych stĺpcových alebo čiarových grafov. Google charts síce poskytuje možnosť načítavať údaje priamo zo zdieľaných xls dokumentov, vďaka čomu je pridávanie a editácia údajov veľmi rýchla, ale zároveň nastáva v našom prípade problém. Čítanie veľkého xls dokumentu a následné vykonávanie triedení a prepočtov by bolo v našom prípade veľmi neefektívne, Keďže predpokladáme množstvo používateľov využívajúcich aplikáciu súčasne. V tomto smere nás Highcharts oslovil viac, a ako bonus má oveľa krajšie a plynulejšie animácie, čo určite zanechá lepší dojem na používateľa. 16

22 2.4 Podobné portály, inšpirácia Na Slovensku sa zatiaľ žiadna podobná webová aplikácia nevyskytuje, takže sa budeme musieť inšpirovať zahraničnými portálmi. Našim cieľom nie je, aby aplikácia robila to isté čo zahraničné aplikácie. Chceme, aby to robila lepšie a hlavne pristupovala k problematike trochu inak. Jednou zo vzorových aplikácií je ktorý ale určite nie je bezchybný a v našej aplikácii chceme riešiť niekoľko vecí inak. Medzi klady môžeme zaradiť: prehľadné a intuitívne rozhranie možnosť zvoliť si krajinu, ktorej informácie chceme vykresliť výber časovej periódy (obdobia) zvolenie typu grafu Medzi zápory môžeme zaradiť: časté chybové hlášky odporujúce si s možnosťami funkcionality, ktoré nám autor ponúka nemožnosť upravovať už vykreslený graf nemožnosť jednoducho exportovať tabuľky alebo grafy žiadne dáta o Slovensku Samozrejme existuje množstvo vizualizačných nástrojov a aplikácií zameraných na iné odvetvia. Náš návrh s týmito riešeniami neporovnávam zámerne, nakoľko chcem zdôrazniť fakt, že ani naše susedné krajiny nedisponujú podobnou aplikáciou. Samotné algoritmické riešenie nie je vo svojej podstate nič revolučné. Tu ale treba zohľadniť aj fakt, že nevytvárame nejakú novú, revolučnú aplikáciu. A ako nás aj v škole učia, vynaliezať znovu koleso je strata času (samozrejme, ak na to nemáme vážny dôvod). Takže sa pokúšame vylepšovať a používať množstvo už existujúcich riešení. Samozrejme prispejeme aspoň malou časťou do digitálnej revolúcie Slovenskej republiky a digitalizovania údajov, čo je svojím spôsobom veľký posun vpred. Hľavne keď si uvedomíme, v akom stave sú aktuálne zozbierané dáta za posledných 25 rokov. 17

23 2.4.1 Súčasný stav webovej aplikácie V súčasnosti neexistuje na Slovensku žiadna oficiálna webová aplikácia, ktorá by nám umožňovala zobrazovať informácie ohľadom financovania politických strán. Jediný možný zdroj je knižné vydanie od organizácie IVO (Inštitút pre verejné otázky) - Financovanie politických strán z roku Síce tu už pár pokusov o vytvorenie podobnej aplikácie bolo, skoro každý skončil z nášho pohľadu neúspechom (nakoľko žiaden nebol dokončený alebo spustený do prevádzky). 18

24 Kapitola 3 Návrh 3.1 Logika navrhovaného systému Na to, aby sme vedeli dostatočne podrobne popísať a navrhnúť náš informačný systém, potrebujeme systém rozdeliť na niekoľko častí. Tie by mali byť funkčné nezávisle od seba, teda náš predpoklad je, že každá časť bude môcť bežať na rozdielnych serveroch. Zároveň potrebujeme zabezpečiť aj dostatočnú robustnosť systému (schopnosť tolerovať rôzne nepredpokladané chyby) a aj určitú formu bezpečnosti. Po zvážení všetkých kritérií budeme deliť systém na 3 základné časti, a to: databázová časť serverová časť (systém veľmi podobný Rest API) webová aplikácia (frontend) Nakoľko sa jedná o projekt z praxe, ktorý bude reálne používať množstvo ľudí, nemohli sme sa pri navrhovaní riadiť len tým, že použijeme nástroje a techniky, ktoré dobre poznáme a vieme s nimi pracovať. Zároveň sme dostali aj požiadavky na systém od zadávateľov (Inštitút pre verejné otázky a Ui42), vďaka čomu sme museli nájsť množstvo nových spôsobov, ako vyriešiť daný problém. Vďaka tomu je naša implementácia rozsiahla vo forme množsta použitých, a samozrejme správne použitých, technológií. Je možné, že v akademickej rovine by sme podobný systém navrhovali a programovali trochu inak, ale vo výsledku by pokytoval rovnakú funkcionalitu. 19

25 3.2 Databázový návrh Naša databáza bude reprezentovaná pomocou databázového typu MySQL a bude ju tvoriť niekoľko tabuliek. Dôvod výberu bol jednoduchý. Je to systém prispôsobený priamo PHP a potrebám webových aplikácií, nie je problém spustiť MySQL databázu na serveroch, ktoré budeme mať k dispozícii a zároveň sám zadávateľ vyžadoval použitie tohto typu. Ako sme už spomínali v predchádzajúcich častiach, ak by sa jednalo o čisto akademický projekt, rozhodli by sme sa určite pre využívanie PostgreSQL databáz, ktoré by nám vedeli poskytnúť niekoľko zaujímavých funkcií (ale zároveň by nijako nepozmenili funkcionalitu, len by zlepšili kvalitu a čistotu nášho kódu). Ako prvú vec sme si museli uvedomiť a jednoznačne definovať, čo všetko si potrebujeme pamätať v databáze. Určite potrebujeme vedieť z databázy zisťiť nasledujúce údaje: názov politickej strany druh príjmov roky, na ktoré sa príjmy a výdaje vzťahujú výdaje politických strán počas volebného obdobia Vo výsledku sa nebude jednať o veľmi mohutnú databázu, ale aj v tomto sa prejaví kvalita návrhu. Neefektívne navrhnutá databáza by obsahovala množstvo duplikátov dát, dáta by bolo potrebné aktualizovať vo viacerých tabuľkách, vzniklo by množstvo nepotrebných tabuliek atď. To všetko by sa prejavilo počas implementácie a bolo by potrebné množstvo neefektívnych prechodov a cyklov, aby sme sa dostali k požadovaným dátam, prípadne aby sme zapísali dáta správne na všetky miesta. Preto sme dbali na dodržiavanie štandardu, že každá tabuľka obsahuje len tie dáta, ktoré sa jej týkajú (súvis aj s názvom tabuľky). Samotný diagram s návrhom databázy možeme vidieť na obrázku 3.1 na konci sekcie Tabuľka s názvami politických strán V tejto tabuľke, v návrhu pomenovanej NAME, si budeme pamätať meno politickej strany reprezentované stĺpcom name a jej kľúč, ktorý bude reprezentovaný stĺpcom id. Chceme zaručiť, že každá politická strana bude v tabuľke reprezentovaná len jedným 20

26 záznamom. Toto nám zabezpečí databázová funkcia Unique(), ktorú nastavíme stĺpcu name. Tabuľka bude obsahovať ešte niekoľko stĺpcov, ktoré vyžaduje Laravel framework na zabezpečenie správnej a plnohodnotnej funkcionality, ako napríklad stĺpec TimeStamp, v ktorom si ukladáme dátum a čas vytvorenia (pridania) hodnoty (v našom prípade mena strany). Aby sme sa vedeli dostať k ďaľším údajom pre danú politickú stranu, budeme využívať kľúč strany (id) na pristupovanie do tabuľky YEAR. Ďaľším dobrým dôvodom, prečo mať názvy politických strán oddelené v samostatnej tabuľke je, že neskôr počas implementácie bude potrebné vypisovať napríklad možnosti na výber strany. Získanie týchto dát bude teraz celkom rýchle, keďže nám stačí vrátiť všetky záznamy stĺpca name z tabuľky Tabuľka s rokmi Tabuľka YEAR bude už oveľa rozsiahlejšia ako tabuľka s názvami politických strán, nakoľko každá strana potrebuje mať záznam pre daný rok (teda rozmer bude počet strán x počet rokov). V našom prípade bude mať aktuálne veľkost približne 21x23, teda minimálne bude obsahovať 483 záznamov. Stĺpce tabuľky budú reprezentovať: kľúč pre daný rok a stranu, ktorý bude zároveň primárnym kľúčom tabuľky (Primary key). Tento kľúč budeme neskôr využívať na prepojenie platieb a rokov v relačnej tabuľke. Vďaka tomuto riešeniu si zabezpečíme opäť optimalizáciu a zefektívnenie prístupu k dátam, zároveň budeme mať niekoľkonásobne menej záznamov v tabuľke. číselnú hodnotu, ktrorá bude obsahovať rok, ku ktorému sa záznam vzťahuje kľúč politickej strany, ktorej sa dané údaje budú týkať (Foreign key). Dôvod pamätania si tejto hodnoty je jednoduchý. Jedna strana bude reprezentovaná vo viacerých rokoch, ale zároveň potrebujeme mať prístup len k názvom politických strán. Pamätanie si kľúča je jedno z najefektívnejších riešení. Tabuľka musí samozrejme obsahovať ešte aj stĺpce, ktoré vyžaduje samotný framework Laravel, ako napríklad TimeStamp. Tieto stĺpce budú musieť obsahovať všetky tabuľky databázy. 21

27 3.2.3 Tabuľka s platbami Jedna z najrozsiahleších tabuliek databázy. Pri návrhu tejto tabuľky sme dlho váhali, akou cestou sa vydať. Či tabuľku rozdeliť na niekoľko menších tabuliek a následne ich poprepájať pomocou relačných tabuliek, alebo vytvoriť jednu väčšiu tabuľku, ktorá bude obsahovať niekoľko stĺpcov (v našom prípade minimálne sedem). Keď sme sa nad problémom neskôr zamysleli, tak aj keď sa jedná o našu najväčšiu tabuľku, na pomery a rozsiahlosť dnešných databáz je celkom malá a jej delením by sme nezískali žiadnu výhodu v oblasti rýchlosti. Zároveň potrebujeme pristupovať vždy ku všetkým dátam, čiže delenie by nám nezabezpečilo ani efektivitu, keďže musíme prejsť každý záznam. Vieme, že bude obsahovať minimálne 483 záznamov (riadkov), teda podobne ako tabuľka s rokmi. Stĺpce tabuľky budú reprezentovať: kľúč tabuľky, pomocou ktorého budeme pristupovať nielen k záznamom tabuľky, ale budeme ho využívať aj pri párovaní dát, resp. ich kľúčov v relačnej tabuľke pre tabuľky PAYMANTS a YEAR. dary, ktorý bude obsahovať celkovú výšku príspevkov, ktoré boli politickej strane darované. Tento typ príspevku pochádza od bežných občanov, resp. nečlenov danej politickej strany príspevky zo SR, ktorý bude obsahovať celkovú výšku príspevkov od Slovenskej republiky za získané hlasy vo voľbách, ktoré sú im každoročne vyplácané. členské príspevky, kde stĺpec bude obsahovať celkovú výšku príspevkov od členov politickej strany. Jediný rozdiel medzi darom a týmto typom príspevku je, že dary nepochádzajú od straníkov. vlastné aktivity, stĺpec bude obsahovať celkové zisky politickej strany za dané obdobie všetky zárobky, ktorý bude obsahovať súčet všetkých príjmov politickej strany Ak strana v danom období ešte neexistovala, alebo už zanikla, bude obsahovať hodnotu 0 (pozor, nie null). Je to z toho dôvodu, že ak budeme využívať získané dáta na vizualizáciu pomocou Highcharts, vizualizácia by nefungovala správne. Zároveň si 22

28 týmto riešením ušetríme jeden až dva prechody cyklom počas každého získania dát z Rest API. Tabuľka samozrejme musí obsahovať aj stĺpce vyžadované frameworkom Laravel Relačná tabuľka na prepojenie rokov a platieb Relačná tabuľka YEAR_has_PAYMENTS bude obsahovať dva stĺpce, a to kľúč pre tabuľku YEAR a kľúč pre tabuľku PAYMENTS, ktoré spolu tvoria pár. Vďaka tejto väzbe sa vieme dostať od názvu politickej strany, cez rok až po prislúchajúce platby. Zároveň je potrebné podotknúť, že ani jeden z kľúčov nie je primárnym kľúčom. Oba stĺpce sú typu foreign key a poukazujú na primárne kľúče tabuliek PAYMENTS a YEAR. Síce nám prišlo v tomto prípade zbytočné implementovať aj stĺpce s časmi vytvorenia, ale framework je v tomto prípade nekompromisný, ak chceme využívať výhody, ktoré nám poskytuje. Na rovnakom princípe je založená aj relačná tabuľka EXPENSES_has_YEAR Tabuľka s výdajmi V tomoto prípade sa jedná o jednu z menších tabuliek, nakoľko výdaje politických strán sa udávajú len za roky, v ktorých prebiehali voľby. Aby sme dodržali ideu čo najväčšej jednoduchosti databázy, budeme využívať prepojenie výdajov pomocou relačnej tabuľky s tabuľkou obsahujúcou roky. Tabuľku budú tvoriť nasledovné stĺpce, ktoré budú reprezentovať: volebné výdaje danej politickej strany počet získaných hlasov vo voľbách kľúč tabuľky, pomocou ktorého budeme pristupovať nielen k záznamom tabuľky, ale budeme ho využívať aj pri párovaní dát, resp. ich kľúčov v relačnej tabuľke pre tabuľky EXPENSES a YEAR. Ak strana v danom období ešte neexistovala, alebo už zanikla, bude obsahovať hodnotu 0 a nie null. Jedným z dôvodov, prečo si pamätáme aj počet získaných hlasov je, že neskôr vďaka tomu bude možné vizualizovať napríklad cenu (hodnotu) každého získaného hlasu a teda tvoriť zaujímavé štatistiky. 23

29 3.3 Návrh Rest api Obr. 3.1: Ukážka diagramu s návrhom databázy Prv než si začneme vôbec popisovať náš návrh, pokľadáme za dôležité si objasniť, čo nás viedlo k tomu, prečo sme oddeľovali webovú aplikáciu (frontend) od serverovej časti. Hlavným dôvodom bolo plánované ponúkanie služieb nášho Rest API aj tretím stranám, ktoré by mali záujem vytvoriť vlastné vizualizačné riešenia. Takže úlohou nášho Rest API bude vracať dáta vo formáte JSON, ktoré budú získané pomocou databázových selectov z našej databázy. Návrh nášho Rest API by sme mohli rozdeliť do niekoľko menších častí, a to na: databázové controllery a migrácie hlavné funkcie - controllery správa ciest - routovanie Postupne si popíšeme jednotlivé časti samostatne, nakoľko každej z nich je potrebné venovať dostatok pozornosti. 24

30 3.3.1 Migrácie V kapitole 3.2 sme si dostatočne podrobne popísali logiku a návrh tabuliek databázy. Keďže chceme využívať čo najviac funkcí a vylepšení, ktoré nám framewok Laravel poskytuje, vytváranie databázy bude prebiehať formou spúšťania migrácií. Každá jedna tabuľka je zapísaná vo vlastnej triede (resp. vlastnom súbore), ktorá obsahuje schému danej tabuľky databázy. Dôvodom, prečo sme si zvolili spôsob vytvárania tabuliek v databáze pomocou migrácií a nie čiste len pomocou SQL scriptu, je jednoduchosť používania a rýchlosť. Náš kód bol počas tvorby testovaný na rôznych zariadeniach, takže na vytvorenie tabuliek stačilo zavolať len v príkazovom riadku príkaz php artisan migrate, ktorý sa postaral o všetko potrebné. Zároveň ak bolo potrebné vykonať zmeny v štruktúre tabuľky, editácia triedy migrácie bola oveľa jednoduchšia, rýchlejšia a hlavne prehľadnejšia ako upravovať klasický SQL script. Konkrétne príklady si popíšeme a ukážeme v implementačnej časti Triedy funkcií - Controllery Jadro našej práce budú tvoriť triedy funkcií, ktoré sú v Laravely nazývané controllery. Aby sme zachovali prehľadnosť a čistotu kódu, funkcie budeme mať rozmiestnené v súboroch s názvom prislúchajúcim k ich funkcii. Ak by sme si chceli rozdeliť funkcie do menších častí, alebo podkategórií, členenie by vyzeralo nasledovne: funkcie na vkladanie a aktualizovanie údajov v databáze funkcie na získavanie údajov z databázy Samozrejme na prácu s databázou potrebujeme mať správne naimplementované databázové controllery, ale k tejto časti sa budeme bližšie vyjadrovať až počas implementačnej časti. Čistota kódu a dodržiavanie aspoň niektorých hlavných štandardov by mala byť pri práci na rozsiahlom projekte samozrejmosť, preto sa snažíme dodržiavať presnú hierarchiu umiestnenia súborov, ktorú nám poskytuje aj samotný framework. Vkladanie a aktualizovanie údajov Pri navrhovaní tejto časti sme sa museli potýkať s množstvom otázok, nakoľko zadávateľ mal celkom odlišné predstavy ako by malo byť riešené vkladanie a aktualizovanie 25

31 Obr. 3.2: Ukážka štruktúry adresárov v projekte údajov. Našim pôvodným plánom bolo vytvoriť webové rozhranie, pomocou ktorého by sa administrátor prihlásil a server nahral svoje dáta. Ale po stretnutiach so zadávateľom sme sa zhodli, že zvolíme iný, jednoduchší prístup. Keďže dáta budú aktulizované len niekoľkokrát ročne (minimálne raz po vydaní výročných správ o financiách politických strán) rozhodli sme sa pristúpiť na riešenie pomocou nahratia dokumentu pomocou ftp klienta do adresára uploads na servery. Na tento súbor sa následne cez webové rozhranie (zavolanie adresy servera a funkcie) vykoná čítanie, rozparsovanie dát a následný update databázy. Podmienkou zadávateľa tiež bolo, že súbor bude vo formáte.xlsx, teda tabuľka vytvorená programom Excel od spoločnosti Microsoft. Samozrejmosťou v tejto časti implementácie bude využívanie našich databázových funkcií (controllerov). 26

32 Získavanie údajov Nakoľko Rest api má presne špecifikované akým spôsobom majú byť dáta vracané, je potrebné týmto kritériám prispôsobiť aj spôsob spracovania získaných údajov. Základnou logikou tejto časti bude vyberanie dát z databázy pomocou využívania prepojení tabuliek (joinovanie). Získané dáta bude potrebné rozdeliť do logických celkov (pravdepodobne budeme využívať dátovú štruktúru podobnú slovníkom), ktoré budú následne prerobené do formátu JSON, ktorý bude každá jedna funkcia vracať. Zároveň budeme dbať na univerzálnosť funcií, čím si ušetríme nielen počet riadkov kódu v jednotlivých triedach, ale aj zjednodušíme správu ciest (routovanie). Aby sme zabezpečili spoluprácu jazyka PHP s databázov, nebudeme využívať štandardné funkcie ktoré nám poskytuje čistá verzia PHP, ale takzvané databázové dopyty (database querys) ktorými disponuje upravená verzia jazyka PHP vo frameworku Laravel. Presným podrobnostiam ohľadom získavania údajov sa budeme venovať v implementačnej časti práce Routovanie Ak by sme sa pokúsili preložiť routovanie do slovenčiny, bolo by vhodné ho pomenovať v našom prípade ako správa ciest. Laravel má svoj špecifický spôsob routovania, čo bol aj jeden z hľavných dôvodov prečo sme sa rozhodli aplikáciu programovať v tomto frameworku. Všetky cesty musia byť zadefinované v súbore routes, ktorý obsahuje nami využívané funkcie GET, ktoré ako parameter dostávajú text (resp. by sme ho mohli nazvať aj kľúčom), ktorý keď sa vyskytne v url adrese tak sa načíta nami zvolený controller a vykoná sa vybraná funkcia. Obr. 3.3: Ukážka súboru routes Teda napríklad ak by sme chceli zavolať funkciu getall() z controlleru GetControl- 27

33 ler.class z ukážkového obrázku 3.3, naša url by musela vyzerať nasledovne: kde čať getall (vyznačená hrubým fontom) je parametrom GET funkcie Laravelu. 3.4 Návrh webovej aplikácie Návrhu používateľského rozhrania sme venovali množstvo času a konzultácií. Dôraz sa kládol nielen na funkcionalitu, ale aj na prehľadnosť a intuitívnosť (nakoľko podobná problematika je jedným z hľavných zameraní firmy Ui42). Našim pôvodným plánom bolo vytvorenie samostatnej webovej stránky, ktorá by bola subdoménou už existujúcej webovej stránky Inštitútu pre verejné otázky, ivo.sk. Vzniklo niekoľko grafických návrhov a skíc, no neskôr sme sa zamysleli znovu nad otázkou, čo všetko potrebujeme na stránke zobrazovať. Po odstránení niektorých zbytočných podstránok nám zostala len jedna, hlavná stránka, ktorá by okrem grafov, tabuliek a výberového filtra neobsahovala nič iné. Preto sme pristúpili na nové riešenie, a to že naša aplikácia bude implementovaná do už existujúcej webovej stránky, ktorej bude vyčlenená samostatná sekcia v stránke. Už počas našej implementácie sme teda pracovali s predpokladom, že výsledná webová aplikácia bude obsiahnutá len v jednej sekcii (alebo html div elemente). Obr. 3.4: Ukážka pôvodného grafického návrhu webovej aplikácie 28

34 3.4.1 Grafický návrh dizajnu Hlavným cieľom grafického dizajnu bude minimalistická, intuitívne použiteľná webová aplikácia. Prioritou by malo byť sústrediť pozornosť používateľa na hlavný obsah stránky, teda na grafy a tabuľky a nemal by byť ničím rušený. Preto by bolo vhodné pri grafickom návrhu: využívať čo najmenej výrazných dizajnových prvkov dbať na dostatočný farebný kontrast. Prevládať by mala biela farba pozadia a kontrastovať by jej mal vybraný odtieň modrej (nakoľko hlavná stránka ivo.sk využíva kombináciu modrej a bielej) myslieť na rozdielnosť zariadení a veľkosti zobrazovacích plôch, teda web by mal byť responzívny a použiteľný na každom zariadení dbať na čitateľnosť a prehľadnosť textov 3.5 Predpokladaná funkcionalita V tejto časti je popisovaná prevažne funkcionalita webovej aplikácie (frontendu) na strane používateľa, nakoľko funkcionalitu Rest API sme popísali už v predošlej kapitole 3.3. Hlavnú funkcionalitu si môžeme jednoducho zhrnúť do niekoľkých bodov: vyberanie kritérií na vykreslenie grafu a tabuľky upravovanie grafu v reálnom čase exportovanie údajov Výber kritérií na vykreslenie grafu Používateľ by mal pred vykreslením požadovaného grafu označiť niekoľko polí (select box, chceckbox... ), pomocou ktorých sa vyfiltrujú údaje a vykreslí sa požadovaný graf. Hlavné možnosti na výber by mali byť: výber rozmedzia rokov, ktoré chce používateľ vykresliť 29

35 výber politických strán výber typu príspevku (napr. dar od člena, dar od občana... ) prepočet z SKK do EUR sa bude vykonávať automaticky, ak bol aspoň jeden zvolený rok väčší alebo rovný roku 2007 výber typu grafu (napr. stĺpcový, čiarový... ) Real-time úprava grafu Všetky kritéria použité vo filtre by sa mali dať meniť v reálnom čase a používateľ by mal okamžite vidieť nový graf bez potreby znovunačítania webovej aplikácie. Po tom, čo sme analyzovali už existujúce vizualizačné aplikácie, sme sa všetci zhodli na tom, že odstránenie tlačidiel a automatické načítanie zvolených údajov zanechá dobrý dojem na používateľa a zároveň spríjemní používanie aplikácie. Táto funkcia existujúcim riešeniam chýbala Export údajov Po vykreslení grafu by mal mať používateľ možnosť jednoducho exportovať vykreslené údaje vo forme grafu alebo tabuliek. Exportované grafy alebo tabuľky bude rovnako jednoduché vytlačiť alebo uložiť lokálne do počítača používateľa Vkladanie nových údajov Túto funkcionalitu budú mať sprístupnenú len zamestnanci (správcovia aplikácie) organizácie IVO. Databáza už bude obsahovať všetky aktuálne zozbierané údaje importované z.xls súboru. Nové údaje správca pridá jednoducho pomocou importovania nového rozšíreného.xls súboru, z ktorého API načíta údaje, roztriedi a zapíše ich do databázy. Po kažkom vložení nových údajov nebude potrebné nič meniť na fungovaní webovej aplikácie. Vkladanie bude prebiehať pomocou prihlásenia sa cez ftp klienta na server a nahratie (prepísanie) súboru v adresári vyhradenom pre tieto účely. 30

36 3.6 Typy návštevníkov Je potrebné si uvedomiť, že webová aplikácia nebude slúžiť len odbornej spoločnosti, ale aj bežným občanom. A tomu by mala zodpovedať aj reprezentácia zobrazovaných informácií. Typický používateľ webovej aplikácie by sa dal teda špecifikovať nasledovne: Odborná verejnosť vekové rozhranie od 25 rokov informácie nevyužíva len na vlastné vzdelávanie, ale zároveň informácie zistené z portálu budú použité v jeho práci, výskume, vyjadrení... zaujíma sa o podrobné informácie, ako napr. tabuľky s dátami, grafy využíva pokročilejšie funkcie aplikácie Verejnosť vekové rozhranie od 18 rokov nemá záujem o zložité a podrobné tabuľky, väčší dôraz kladie na jednoduché a prehľadné grafy a porovnania informácie vyhľadáva hlavne v období volieb Zamestnanec IVO zodpovedný za aktuálnosť údajov spravuje a nahráva nové tabuľky Mladý človek, vek od rokov často prvovolič, prípadne mladý volič zisťuje informácie ohľadom histórie financovania politickej strany kandidujúcej vo voľbách informácie zistené na portále môžu byť rozhodujúce pri tvorbe mienky o politickej strane a môžu pomôcť definitívne sa rozhodnúť, koho bude voliť informácie sú pre neho zaujímave často len počas volebného obdobia 31

37 3.6.2 Občan vo veku nad 25 rokov má približný prehľad a povedomie v pôsobení politických strán zisťuje informácie ohľadom histórie financovania politických strán kandidujúcich vo voľbách informácie zistené na portále môžu byť rozhodujúce pri tvorbe mienky o politickej strane a môžu pomôcť definitívne sa rozhodnúť, koho bude voliť informácie sú pre neho zaujímave často len počas volebného obdobia, alebo počas výnimočných udalostí v politickom dianí Odborná verejnosť (napr. novinár) vo veku nad 25 rokov náplňou jeho každodennej práce je zaoberanie sa situáciami a aktualitami z politického diania zisťuje informácie nielen počas volebného obdobia, ale počas celého roka informácie nevyužíva len na vlastné vzdelávanie, ale ich aj šíri do povedomia širšej verejnosti, prípadne ich využíva vo vlastnom výskume medzi odbornú verejnosť môžme zaradiť aj samotných reprezentantov a členov politických strán Zamestnanec organizácie IVO jeho úlohou je udržiavať aplikáciu aktuálnou výsledky svojej práce publikuje na webovom portáli, kde budú následne okamžite dostupné pre širokú verejnosť väčšina nahraných dát je vo forme tabuliek, ktoré budú reprezentované aj v grafovej forme 32

38 Kapitola 4 Implementácia V tejto časti práce sa budeme podrobnejšie venovať programovaniu nami navrhnutej aplikácie. Nakoľko sme návrhu venovali dostatočne veľkú pozornosť a premysleli všetky detaily, realizácia sa zaobišla bez väčších problémov. Samozreme sme sa často dostávali do fáz vývoja, kedy sme zistili, že dokážeme niektoré časti aplikácie naprogramovať oveľa efektívnejšie za pomoci využitia ďaľších technológií. Vďaka tomu sa náš návrh mierne menil aj počas implementácie. Jedným z príkladov môže byť využívanie jquery, o ktorého použití sme pôvodne vôbec neuvažovali. Pri popise implementácie sa venujeme konkrétne implementácii časti práce, kde riešime financovanie politických strán. Nakoľko časť s výdajmi využíva prakticky totožné, miestami zjednodušené časti kódu a funkcie z financovaia, nevenovali sme jej pri popise implementácie veľkú pozornosť (z dôvodu opakovania sa). Ak sme počas implementácie výdajov narazili na akýkoľvek nečakný problém, bude popísaný samostatne v tejto kapitole. 4.1 Rest api - serverová časť Ako prvej časti som sa logicky venoval rest API, ktoré tvorí hlavnú funkcionalitu nášho projektu. Nakoľko sme sa rozhodli že budeme používať framework jazyka PHP, Laravel (vo vtedy aktuálnej verzii 5.3), bolo potrebné vykonať niekoľko úkonov, aby sme vôbec dokázali projekt spustiť. Medzi základné veci, ktorým sa treba venovať, je vytvorenie databázy a následné nastavenie spojenia s ňou priamo v databázovom konfiguračnom súbore. Ďalej je potrebné zadefinovať všetky nástroje a rozšírenia, ktoré plánujeme používať, inak by sme narážali na množstvo problémov, ako napríklad nemožnosť volať 33

39 databázové migrácie, vykonávanie aktualizácií komponentov atď. Na záver bolo treba už len vygenerovať vlastné bezpečnostné kľúče a.config súbor. Celý podrobný postup je popísaný v dokumentácii frameworku [6]. Asi jediné podstatné rozšírenie, ktoré sme v našom projekte potrebovali implementovať, bolo PHPExcel, ktoré slúži na čítanie a vytváranie.xlsx dokumentov. Samozrejme sme využívali aj iné rozšírenia, ale tie mali za úlohu len naučiť naše IDE syntax Laravelu a ponúkať nám automatické dopĺňanie kódu Vytvorenie migrácií Už v návrhovej časti sme počítali s tým, že na vytvorenie tabuliek databázy nebudeme využívať klasické create scripty, ale laravelovské migrácie. Migráciu vytvoríme jednoduchým zavolaním konzolového príkazu php artisan make:migration create_users_table, ktorý nám v adresári migrácií vytvorí nový php súbor. Migráciu tvoria 2 hlavné funkcie, a to funkcia up(), ktorá zabezpečuje vytvorenie schémy tabuľky a zadefinovanie dátových typov jednotlivých stĺpcov, a funkcia down(), po ktorej zavolaní sa vykoná prikaz na zmazanie tabuľky. Obr. 4.1: Ukážka migračnej triedy 34

40 Migrácie sa vykonajú po zadaní príkazu php artisan migrate. Samozrejme bolo potrebné vytvoriť migračné triedy pre všetky naše tabuľky Načítanie a uloženie dát do databázy Vstupné súbory, z ktorých sa načítavajú dáta sú vo formáte.xlsx, teda súbory z programu Excel. Aby sme dokázali čítať jednotlivé stĺpce a riadky tabuľky, bolo potrebné využiť rozšírenie PHPExcel, vďaka ktorému môžme prechádzať celú tabuľku pomocou cyklov. V tejto časti programovania Rest API sme strávili asi najviac času, nakoľko bolo potrebné si zvoliť správnu dátovú štruktúru. Ale keďže sa nachádzame v jazyku PHP, množstvo potrebných dátových štruktúr (napríklad slovníky) sme si museli sami manuálne vytvárať. Vedeli sme, že každá politická strana bude mať n rokov záznamov, a ku každému roku bude prislúchať 5 riadkov tabuľky s typmi príspevkov. Takže naša dátová štruktúra vyzerá následovne: kľúčom slovníka (dict) je rok, teda celočíselná hodnota v rozmedzí každý rok obsahuje v poli slovíky, ktorých kľúčom je názov politickej strany každá politická strana obsahuje pole 5 hodnôt, ktoré reprezentujú jednotlivé sumy príspevkov Dáta do tabuliek už potom vkladáme len pomocou prechádzania tejto štruktúry, pričom využívame nami vytvorené funkcie pre vkladanie dát. Tak isto ako migráciami, disponuje Laravel aj svojimi vlastnými verziami databázových volaní (Database Querys). Na ich využívanie bolo potrebné si vytvoriť triedu, ktorej sme dali rovnaké meno ako tabuľke, v nej sme si zadefinovali, že rozširujeme triedu Model, a vytvorili sme si 2 chránené (protected) premenné, ktoré obsahujú skutočné meno tabuľky a pole názvov stĺpcov, do ktorých chceme zapisovať. Triedu v našom prípade tvorí insert() funkcia a v niektorých prípadoch aj get() funkcie. Výhodou takto pripravených tried je aj možnosť pristupovať k tabuľkám ako k objektom, a stĺpcom ako k atribútom triedy (podobný princíp ako napr. jdbc v jazyku Java). Jednotlivé funkcie potom využívame v Laravelovských Controlleroch, ktoré obsahujú náš kód. Aktualizovanie údajov sa rieši formou vymazania dát z tabuliek, a novým zapísaním aktuálnych údajov. Dôvod, prečo sme si zvolili tento spôsob bol, že stále musíme prejsť celý súbor a vytvoriť 35

41 dátovú štruktúru, čo je časovo najviac zložitá časť. Následným porovnávaním hodnôt v tabuľke a aktualizovaním len zmenených by sme neušetrili žiaden čas, keďže stále musíme prechádzať všetky dáta. Preto je pre nás aj z hľadiska predchádzaniu chybám jednoduchšie všetky tabuľky premazať a naplniť ich novými údajmi. Brali sme do úvahy aj skutočnosť, že používateľ nemá k dispozícii žiaden nástroj na editovanie obsahu tabuliek (mimo phpmyadmin a pod.). Obr. 4.2: Ukážka časti kódu na prechod vstupného súboru Získavanie a vracanie dát Všetky funkcie, ktoré majú za úlohu vracať dáta po zavolaní určitej url adresy, sa nachádzajú v triede GetController, ktorá rozširuje triedu Controller. Celá funkcionalita spočíva vo volaniach funkcie getdata(), ktorá z Query Stringu získa parametre pre filtrovanie požadovaného výsledku. V zásade sme teraz k databáze nepristupovali objektovo, ale využívali sa databázové query ktorými disponuje Laravel. Na získanie všetkých požadovaných údajov potrebujeme zadefinovať niekoľko prepojení tabuliek (podľa primárneho kľúča), a na získané výsledky potom použiť wherein podmienku, ktorá nám vráti len údaje obsahujúce vzor, ktorý sa nachádza v porovnávanom poli údajov. Získané dáta vrátime vo formáte JSON, na čo využijeme vstavanú funkciu json_encode($našedáta). Tvorbe Query Stringov sa budeme venovať v implemntačnej časti webovej aplikácie (frontendu). 36

42 4.1.4 Cesty - routes Presný popis implementácie ciest a aj ukážky kódu boli popísané v návrhovej časti Počas implementácie bolo treba správne zadefinovať a pomenovať Get funkcie. 4.2 Webová aplikácia - frontend Realizácia tejto časti projektu bola pre nás kľúčová, a to nielen z dôvodu overenia nášho riešenia Rest API, ale aj kvôli veľkej znovuvyužiteľnosti kódu v reálnej prevádzke. Webová stránka, ktorú používame na prezentovanie našej práce je len ilustračná a má používateľovi ukázať možnosti, ktoré mu aplikácia umožní v reálnej prevádzke. Reálne sa bude v praxi využívať len časť obsahujúca vizualizačné nástroje Filtrovacie nástroje Pri výbere kritérií budeme využívať 3 spôsoby výberu dát, a to chceckbox, select box a multiselect box. Nebudeme využívať základné nástroje jazyka HTML a CSS, ale budeme používať upravené nástroje, ktoré nám zabezpečuje Bootstrap-select API. Jedným z dôvodov, prečo sme si zvolili aj túto formu implementácie, je zachovanie jednotného dizajnu na všetkých platformách a zároveň nám poskytujú nástroje na dynamické vyhľadávanie v reálnom čase medzi vypísanými možnosťami. Aby sme zachovali univerzálnosť kódu a aplikácie, všetky možnosti výberu sa získavajú volaním funkcie Rest API, následným generovaním html kódu pomocou JavaScriptu a na záver volaním renderovacích Bootstrap funkcií sa vpíšu (vykreslia) do div sekcie html kódu. Keďže jednou z podmienok bolo, že grafy sa menia dynamicky po zmene akéhokoľvek kritéria filtra, každý komponent musí mať nastavený onload() parameter, ktorý nám zabezpečí znovunačítanie nami vybranej funkcie. Posledným problémom, s ktorým sme sa museli potýkať v tejto časti bolo, ako získavať označené údaje a ako ich posielať na stranu servera (Rest API). Na prechádzanie elementov sme použili jquery funkcie, ktoré pomocou funkcie each (logikou podobný PHP funkcii foreach) prechádza všetky elementy zadaného elementu a vyberie všetky,ktorým sme nastavili parameter chcecked. 37

43 Obr. 4.3: Ukážka časti jquery funkcie na získanie označených možností Elementy, ktoré tvoria filtrovacie nástroje sa dynamicky menia aj v závislosti od výberu, či chceme vizualizovať financovanie alebo výdavky politických strán. Zmení sa napríklad rozpätie poskytovaných rokov, alebo výber typu financovania. Pri navrhovaní funkcionality a výbere technológií sme pôvodne zabudli na jednu veľmi podstatnú vec. Ako si budeme posielať dáta z aplikácie na server, ak ich nevieme dať priamo ako parameter funkcie? Po hodinách pokusov a testov sme sa rozhodli zvoliť metódu posielania dát pomocou takzvaných Query Stringov, s ktorými dokáže Laravel pracovať pomocou vstavaných funkcií. Dáta sa teda posielajú pomocou upravenej url, kde sa na koniec nami požadovanej url pridáva ešte znak? a za ním nasleduje meno premennej, potom premenná s dátami. Ak chceme posielať viac premenných súčasne, musíme pred názov ďalšej premennej pridať znak &. Výhodou tiež je, že na strane servera pristupujeme ku dátam ako ku dátam vo forme JSON. Ukážka tvorby Query Stringu: var url = + strana + &rok= + rok + &prispevky= + prispevky; Highcharts a spracovávanie dát Dôvody, prečo sme pri implementácii zvolili Highcharts sme popísali už v návrhovej kapitole. Nakoľko sa jednalo pre nás o novú technológiu, s ktorou sme nemali žiadne skúsenosti, museli sme sa potýkať s niekoľkými problémami. Jedným z problémov bolo, ako čo najefektívnejšie zabezpečiť univerzalitu kódu pre rôzne typy vstupov, teda aby nebolo potrebné mať množstvo scriptov pre rôzne používateľské scenáre. Bolo potrebné vytvoriť niekoľko pomocných JavaScriptových funkcií na vytváranie textov s rokmi, menami politických strán a hlavne zabezpečiť vytváranie takzvaných radov (series) údajov, ktoré následne Highcharts vykresluje buď do tabuľky alebo grafu. Samozrejme je potrebné mať aj funkciu na zabezpečenie vykresľovania správneho počtu stĺpcov, 38

44 ktoré reprezentujú vybrané typy príspevkov. Ďalšie pomocné funkcie sa nám strajú o správne prepočty hodnôt, teda ak vizualizujeme dáta do roku 2007, používame SKK, ale akonáhle sa nám vo vybraných rokoch vyskytne už rok 2007, musíme všetky dáta prepočítať na euro pomocou konverzného kurzu. Na záver sme si museli dávať aj pozor na množstvo údajov, teda ak má používateľ označené väčšie časové obdobie, museli sme prepočítavať priemerné hodnoty zo všetkých dát zo zvoleného časového obdobia. Dôvod týcho prepočtov bol jednoduchý. Ak sme chceli jeden typ príspevku reprezentovať pomocou jedného stĺpca, nebola iná logická a prehľadná alternatíva. Vykresľovanie tabuliek priebieha na podobnom princípe ako vizualizácia grafov, teda práca s dátami na pozadí je veľmi podobná. Hlavným rozdielom je, že musíme naše dáta prechádzať jquery cyklom pomocou funkcie each(), a do každej bunky tabuľky vložiť požadovanú hodnotu. Táto časť implementácie bola po načítavaní údajov zo súboru druhou časovo najnáročnejšou časťou, keďže bolo potrebné odladiť množstvo okrajových prípadov. Obr. 4.4: Ukážka časti kódu pre vytvárnie Highcharts grafu 39

45 Kapitola 5 Používateľský manuál V nasledujúcej časti sa vám budeme snažiť popísať presnú funkcionalitu webovej aplikácie a previesť vás všetkými možnosťami nášho systému. Zhrňme si najprv všetky aktuálne možnosti nami vytvoreného systému: aktualizovanie údajov v databáze pomocou zavolania špecifickej url adresy vykresľovanie grafov a tabuliek na základe kritérií vybraných používateľom exportovanie grafov a tabuliek vo formáte jpg, png a svg možnosť tlače vizualizácií priamo v sekundárnom menu v oblasti vizualizácie Pre nahrávanie súborov na vykonanie aktualizácie databázy je potrebné mať prístup priamo na server. Toto riešenie sme zvolili hlavne nielen kvôli jednoduchosti, ale aj bezpečnosti. Snažili sme sa predísť rôznym pokusom o útok a následnému sfalšovaniu údajov. 5.1 Aktualizácie údajov Na to, aby správca mohol vykonať aktualizovanie údajov je potrebné, aby mal prístup na server, kde beží Rest API, a pomocou ftp clienta a pripojenia prekopírovať.xlsx document do adresára/public/ a pomenovať ho ako financovanie.xlsx. Následne stačí ísť na domovskú stránku servera (index.php), ktorej obsahom je stručný výpis funkcií a popis ich funkcionality, z ktorých používateľ vyberie požadovanú funkciu. V našom prípade update. Takže je potrebné za url v prehliadači dopísať /update. Teda celá url 40

46 bude vyzerať nasledovne: Po úspešnom vykonaní aktualizácie údajov dostane používateľ výpis, že aktualizácia prebehla bez problémov. V priípade neúspešnej aktualizácie dostane výpis chybových hlášok. Ak by bol aj vykonaný update aj niekoľkokrát po sebe, tak na obsahu tabuliek databázy sa nič nezmení, keďže sa tabuľka pred aktualizovaním vždy premaže. Obr. 5.1: Ukážka domovskej obrazovky Rest api 5.2 Výber kritérií na vizualizáciu Používateľ musí vybrať aspoň jednu hodnotu v každom elemente filtra, aby bol vykreslený požadovaný graf alebo tabuľka. Ak by však zrušil výber jedného celého elementu (napríklad rok) už po vykreslení, tak sa vykreslí prázdny graf a nespadne na chybovej hláške. Za dôležité pokladáme funkcionalitu, ktorú poskytujú naše multiselect boxy, a to hlavne vyhľadávanie požadovanej hodnoty medzi vypísanými možnosťami. Ďalším výberateľným kritériom okrem multiselect boxov pre roky a názov politickej 41

47 Obr. 5.2: Ukážka multiselect boxu strany je výber typu príspevkov, ktoré su reprezentované formou check boxov. Ak používateľ odznačí niektorú z možností, stĺpec sa hneď vynechá pri vykresľovaní grafu. Obr. 5.3: Ukážka chceck boxov pre výber typu príspevkov Obr. 5.4: Ukážka chceck boxov pre výber typu výdajov 42

48 Posledným vyberateľným kritériom je výber typu grafu. V tomto prípade je možné vybrať len jeden zo 4 ponúkaných typov grafu, preto je implementovaný pomocou jednoduchého selectboxu. V budúcnosti je možné rozšíriť a špecifikovať ponuku grafov. Ak už používateľ vybral aspoň raz typ grafu, musí mať stále zvolený jeden typ. Aj v tomto prípade sa po každej zmene vizualizácia dynamicky mení bez potreby niekam klikať alebo niečo potvrdzovať. Obr. 5.5: Ukážka jednoduchého select boxu pre výber typu grafu Ďalej prikladáme niekoľko ukážok vizualizácií, ktoré by mal používateľ dostať po správnom označení všetkých filtrovacích kritérií. Obr. 5.6: Ukážka stĺpcového grafu Jednotlivé komponenty grafu je možné vypínať priamo vo vizualizácii pomocou kliknutia na názov v legende v spodnej časti grafu. Prejdením kurzorom cez konkrétny stĺpec sa používateľovi zobrazia presné hodnoty, popis, o aký príspevok sa jedná a celkový súčet hodnôt v danom stĺpci. 43

49 Obr. 5.7: Ukážka čiarového grafu a tabuľky Obr. 5.8: Ukážka filtrovania výdajov politických strán Obr. 5.9: Ukážka filtrovania financovania politických strán 44

50 5.3 Exportovanie údajov Highcharts disponuje svojim vlastným sekundárnym menu, ktoré obsahuje niekoľko funkcií. Pre nás boli podstatné len funkcie pre tlač a exportovanie vizualizácií. Vďaka tejto funkcionalite si používateľ dokáže rýchlo a pohodlne stiahnuť alebo vytlačiť požadovanú vizualizáciu. Obr. 5.10: Ukážka sekundárneho menu vo vizualizácii 45