\chapter{Technické riešenie} V tejto časti podrobnejšie popíšeme samotnú implementáciu aplikácie a použité technológie. \section{Moduly} Aplikácia je pomerne veľká a obsahuje časti s odlišnou funkcionalitou. Zvolili sme rozdelenie do viacerých modulov. Moduly majú anglické názvy Data, Competition, GUI. Tieto moduly majú za úlohu rozdeliť funkcionalitu do vrstiev, aby bola implementácia prehľadnejšia. Najnižšia vrstva je Data, nad ňou je Competition a najvyššie je GUI. Ak napríklad vrstva GUI chce vykresliť objekt na obrazovku, spýta sa vrstvy Competition, aké má objekt súradnice. Táto vrstva sa spýta vsrtvy Data, ktorá sa spojí s databázou. Komunikácia dvoch vrstiev vyzerá tak, že v obidvoch vrstvách existujú objekty s rovnakým menom a objekt vyššej vrstvy je zaobalením objektu nižšej vrstvy. Pod zaobalením máme na mysli to, že objekt vyššej vrstvy si pamätá referenciu na objekt nižšej vrstvy a pridáva k nemu ďalšiu funkcionalitu. Okrem referencie na objekt z nižšej vrstvy, preto obsahuje len metódy rozširujúce funkcionalitu alebo zaobaľujúce funkcionalitu nižšej vstvy. Každý modul tvorí svoj vlastný menný priestor -- Orienteering.Data, Orienteering.Competition a Orienteering.GUI. \subsection{Modul Data} Jedinou úlohou tohto modulu je komunikovať s databázou. Modul Competition preto ani nevie, že dáta sa v skutočnosti vyberajú z databázy. \begin{figure} \begin{center} \includegraphics[width=12cm]{uml} \caption{UML diagram pre triedy modulu Data (neobsahuje metódy)} \label{fig:uml} \end{center} \end{figure} \subsection{Modul Competition -- Preteky} V module Competition (po slovensky preteky) sa nachádza veľká časť funkcionality. Keď sa preteky ukladajú do súboru, v činnosti je práve tento modul. Alebo keď sa vyhodnocujú výsledky, losuje štartová listina a exportujú výsledky. \subsection{Modul GUI -- Grafické rozhranie} Grafické rozhranie nerobí žiadne operácie s dátami, iba komunikuje s používateľom a požiadavky posiela nižšej vrstve (Competition). Takisto sa stará o vykresľovanie tratí na obrazovku alebo o export do grafických formátov. \section{Použité knižnice} Pri výbere programovacieho jazyka malo najväčšiu váhu to, aby bola aplikácia multiplatformná. Vybrali sme si jazyk C\#, pretože popri originálnej implementácii od spoločnosti Microsoft existuje aj implementácia Mono od firmy Novell, ktorá beží aj na Unixe. Navyše je automaticky k dispozícií .NET Class Library, ktorá obsahuje veľa užitočných funkcií -- napríklad kompresný algoritmus Gzip alebo knižnicu na prácu s XML. Grafickú knižnicu sme si vybrali GTK\#. Druhá možnosť bola použiť Windows.Forms, ale táto implementácia používa umiestňovanie grafických prvkov elementov podľa absolútnych súradníc v pixeloch, čo je v súčasnosti zastaralý prístup. Druhou veľmi dôležitou knižnicou je knižnica Db4o. To je objektová databáza, ktorá si pamätá priamo objekty z jazyka C\#. Databázový dopyt v nej sa robí tak, že ako požiadavku odovzdávame funkcii napísanú v jazyku C\#, ktorá vracia boolovskú hodnotu. Táto funkcia je v skutočnosti predikát. Databáza vráti všetky objekty, ktoré daný predikát spĺňajú. V nasledovnej ukážke je dopyt, ktorý vráti kontrolné stanovište s daným číslom: \InputC{db4o.cs} Parameter {\tt delegate(Control control)} je predikát, ktorý odovzdávame databáze ako parameter. Ako vidíme, predikát spĺňajú iba kontrolné stanovištia s daným číslom a v danej etape (stage). \section{Spolupráca modulov} V diagramoch \ref{fig:sequence1} a \ref{fig:sequence2} vidíme, čo sa medzi modulmi udeje, keď si používateľ chce zobraziť všetky kategórie danej etapy a keď chce uložiť súbor. \begin{figure} \begin{center} \includegraphics[width=12cm]{sequence1} \caption{Sekvenčný UML diagram spolupráce modulov pri editácii kategórií} \label{fig:sequence1} \end{center} \end{figure} \begin{figure} \begin{center} \includegraphics[width=12cm]{sequence2} \caption{Sekvenčný UML diagram spolupráce modulov pri ukladaní súboru} \label{fig:sequence2} \end{center} \end{figure} \section{Súborový formát} Vytvoriť vhodný súborový formát pre aplikáciu je neľahká úloha. V našej aplikácii sme sa rozhodli použiť prístup známy napríklad z raných verzií produktu OpenOffice. Ako základný formát ukladania dát použijeme formát XML. O jeho výhodách sa zmienime neskôr. Keďže tento formát dokáže objem dát zväčšiť, ešte pred uložením na disk sa súbor skomprimuje kompresným algoritmom Gzip. Počas tvorby práce bol kompresný pomer $1:5$ a lepší. Formát XML sa vďaka stromovej štruktúre hodí pre našu aplikáciu. Vzťahy objektov sú väčšinou hierarchické. Preteky sa skladajú z niekoľkých etáp. Každá etapa obsahuje niekoľko tratí, každá trať môže prislúchať viacerým kategóriám atď. Existujú však aj objekty, ktoré vytvárajú v stromovej štruktúre cykly. Tie sme riešili referenciami na iné objekty pomocou identifikátorov. Keďže objekty ako štart, cieľ a kontrolné stanovište svoje unikátne číslo majú, netreba pre ne vyrábať nový identifikátor. Rovnako každá kategória má jednoznačný názov a ten poslúži ako identifikátor. Nasleduje ukážka jednoduchého XML súboru (pozrieť súbor sa dá v Unixe jednoducho napríklad pomocu príkazu {\tt zcat GPS.oxz}, kde {\tt GPS.oxz} je konkrétny súbor s pretekmi): \begin{verbatim} \end{verbatim} Koreňový element dokumentu je {\tt competition}, teda preteky. Každý súbor obsahuje práve jedny preteky. Každý XML element predstavuje jeden skutočný objekt v aplikácii a vlastnosti elementu sú zároveň vlastnosťami objektu. Ako vidíme v príklade, element pre etapu ({\tt stage}) má napríklad vlastnosť číslo ({\tt number}), čo určuje poradie tejto etapy v pretekoch. Ak má element synov, znamená to, že synovia si uchovávajú referenciu na svojho predka. Napríklad v aplikácii si objekt pre pretekára ({\tt runner}) pamätá referenciu na klub ({\tt club}).