Kapitola 3
N´ avrh
V t´eto kapitole se budu vˇenovat n´avrhu architektury aplikace a provedu v´ybˇer technologi´ı pro implementaci. Hlavn´ım vstupem bude v´ystup pˇredchoz´ı ka-pitoly, tedy anal´yzy. Pro popisky v UML diagramech jiˇz nebude pouˇz´ıv´ana ˇ
ceˇstina ale angliˇctina. Je to z toho d˚uvodu, ˇze jednotliv´e elementy budou vˇetˇsinou pˇredstavovat nˇejak´e elementy ve zdrojov´ych souborech aplikace. Pˇri programov´an´ı bude totiˇz pouˇz´ıv´ana angliˇctina.
3.1 Verze Javy a GUI
Verze Javy byla vybr´ana Java SE 8, jelikoˇz je pro ´uˇcely aplikace dostaˇcuj´ıc´ı.
Vyˇsˇs´ı verze nebyla zvolena, protoˇze budouc´ı uˇzivatel´e aplikace mohou m´ıt st´ale nainstalovanou verzi 8. Pro testov´an´ı budou pouˇzity jednotkov´e testy pomoc´ı JUnit verze 5.
Pro GUI bylo moˇzno vyb´ırat z v´ıce moˇznost´ı. Jedn´a se napˇr´ıklad o AWT, Swing, SWT, JavaFX. Zvolil jsem JavaFX, jelikoˇz je to nejnovˇejˇs´ı GUI fra-mework od firmy Oracle Corporation. Pro statickou definici GUI lze vyuˇz´ıt FXML form´at soubor˚u, ˇc´ımˇz lze oddˇelit tuto definici s vlastn´ım programov´an´ım funkˇcnost´ı. Tento form´at soubor˚u je rozˇs´ıˇren´ım form´atu XML. Lze ho upra-vovat manu´alnˇe ˇci pouˇz´ıt speci´aln´ı aplikaci. Firma Oracle Corporation nab´ız´ı aplikaci JavaFX Scene Builder. Tuto aplikaci budu vyuˇz´ıvat, jelikoˇz velmi usnadn´ı pr´aci.
3.2 Architektura aplikace
Aplikace bude dle nefunkˇcn´ıch poˇzadavk˚u desktopov´a a multiplatformn´ı.
Vˇsechny jej´ı ˇc´asti budou bˇeˇzet na jednom poˇc´ıtaˇci. Multiplatformita bude zaruˇcena pouˇzit´ım programovac´ıho jazyku Java. Bude tak´e Pro rozdˇelen´ı soft-warov´ych modul˚u jsem zvolil tˇr´ıvrstvou architekturu, obsahuj´ıc´ı prezentaˇcn´ı, business a datovou vrstvu. Pˇresnˇeji ˇreˇceno se jedn´a o jej´ı relaxovanou verzi,
3. N´avrh
kdy prezentaˇcn´ı vrstva m˚uˇze vyuˇz´ıvat entity z datov´e vrstvy. V´yhodou je jednoduˇsˇs´ı implementace. Jinak by napˇr´ıklad musely b´yt entity mapov´any na jin´e objekty v business vrstvˇe. Na obr´azku 3.1 je UML diagram zobra-zuj´ıc´ı vˇsechny vrstvy aplikace. Jedn´a se o UML diagram bal´ıˇck˚u. Tˇr´ıdy za ˇr´ızen´ı turnaje a jeho kol jsou v business vrstvˇe neboli v bal´ıˇcku Business layer.
Tˇr´ıvrstvou architekturu jsem zvolil, abych rozdˇelil zodpovˇednost za GUI, busi-ness logiku a pr´aci s perzistentn´ım ´uloˇziˇstˇem. Jednotliv´e vrstvy bude moˇzno snadno vymˇenit. Napˇr´ıklad se v budoucnu m˚uˇze uvaˇzovat o zmˇenˇe deskto-pov´eho GUI na webov´e rozhran´ı. V n´asleduj´ıc´ıch podkapitol´ach pop´ıˇsi jednot-liv´e vrstvy. Budu nejv´ıce pouˇz´ıvat UML diagram tˇr´ıd. Z d˚uvodu pˇrehlednosti budu zan´aˇset do tˇechto diagram˚u pouze nejd˚uleˇzitˇejˇs´ı atributy a metody.
3.2.1 Prezentaˇcn´ı vrstva
Uˇ´celem t´eto vrstvy bude zobrazov´an´ı dat uˇzivateli a reakce na jeho poˇzadavky.
Tedy napˇr´ıklad reakce na stisknut´ı tlaˇc´ıtka nebo zobrazen´ı seznamu hr´aˇc˚u turnaje. Dle [23] je doporuˇceno pouˇzit´ı vzoru MVC, kde FXML soubory pˇredstavuj´ı jednotliv´e pohledy a kontrolery pak reaguj´ı na akce v GUI. Dle m´eho n´azoru vˇsak v tomto pˇr´ıpadˇe FXML soubory pˇredstavuj´ı v podstatˇe pouze statick´e ˇsablony. Proto jsem zvolil MVP, kter´y se mi zd´a zde lepˇs´ı volba.
Prezentaˇcn´ı vrstvu rozdˇelen´ım na pohledy a prezentery. Obˇe ˇc´asti budou tvoˇreny tˇr´ıdami. Pohledy budou zachyt´avat poˇzadavky z GUI a jejich vlastn´ı zpracov´an´ı deleguj´ı na prezenter. Prezenter zkontroluje dan´y poˇzadavek a po-moc´ı business vrstvy jej zpracuje. Pokud je pot´e potˇreba zobrazit uˇzivateli in-formace, pak pˇrik´aˇze pohledu, aby je zobrazil v GUI. Jedn´a se variantu MVP s pasivn´ımi pohledy, kde pohledy nekomunikuj´ı s objekty z business vrstvy.
Obsahuj´ı minim´aln´ı logiku a v podstatˇe jen zachyt´avaj´ı akce v GUI a zobra-zuj´ı data. Pohledy obsahuj´ı objekty z JavaFX, kdeˇzto prezentery ne. T´ım je dosaˇzeno ide´aln´ıho prostˇred´ı pro budouc´ı testov´an´ı, kdy lze testovat aplikaci bez interakce s GUI, jelikoˇz flow logika zpracov´an´ı poˇzadavk˚u je pˇr´ıtomna jen v prezenterech. To je hlavn´ı d˚uvod, proˇc si mysl´ım, ˇze je zde MVP lepˇs´ı a tedy proˇc jsem zvolil MVP m´ısto MVC s FXML pohledy. D´ale aby se oddˇelily statick´e definice GUI od pouˇz´ıvan´ı objekt˚u, vyuˇz´ıvaj´ı pohledy FXML. Kaˇzd´y pohled patˇr´ı jednomu prezenteru a naopak. Pohledy mezi sebou nekomunikuj´ı.
Vˇse jde pˇres prezentery, kter´y mohou mezi sebou komunikovat.
3.2.2 Business vrstva
Tato vrstva je zodpovˇedn´a za vlastn´ı logiku aplikace. Poskytuje rozhran´ı pro prezentaˇcn´ı vrstvu. Prob´ıh´a zde hlavn´ı validace poˇzadavk˚u. Prezenter z pre-zentaˇcn´ı vrstvy totiˇz validuje jen z´akladn´ı vˇeci. Jedn´a se napˇr´ıklad o to, zda byly vˇsechny pol´ıˇcka vyplnˇeny. Kontrola, zda byly vyplnˇeny spr´avnˇe, prob´ıh´a pˇredevˇs´ım v t´eto vrstvˇe. Business vrstva vyuˇz´ıv´a data z datov´e vrstvy, kter´e
3.2. Architektura aplikace
Presentation layer
Business layer
Data layer
Views Presenters
Entities DAOs
interfaces_for_pl
pairing_engines
ranking_systems
Obr´azek 3.1: Architektura aplikace
3. N´avrh
z´ısk´ava pomoc´ı DAO rozhran´ı z t´eto vrstvy. Kromˇe z´ısk´av´an´ı dat, vyuˇz´ıv´a DAO objekty i pro perzistetn´ı ukl´ad´an´ı dat.
Na obr´azku 3.2 m˚uˇzeme vidˇet hiearchii rozhran´ı a tˇr´ıd pˇredstavuj´ıc´ıch turnaj a tak´e rozhran´ı TournamentManager, kter´e je zodpovˇedn´e za CRUD operace obou typ˚u turnaj˚u. Na obr´azku 3.3 zase hierarchii rozhran´ı a tˇr´ıd pˇredstavuj´ıc´ıch kolo turnaje a jejich z´avislost na rozhran´ı PairingEngine. Jsou zde zaneseny i dvˇe entitn´ı tˇr´ıdy z datov´e vrstvy, pˇredstavuj´ıc´ıch z´apas jed-notlivc˚u a druˇzstev, pro zn´azornˇen´ı vztahu s koly turnaje. Jedn´a se o tˇr´ıdy MatchEntity a TeamMatchEntity.
V t´eto vrstvˇe budou implementov´any tak´e p´arovac´ı enginy a pomocn´a hod-nocen´ı. Jednokolov´y a dvoukolov´y syst´em kaˇzd´y s kaˇzd´ym a vyˇrazovac´ı syst´em bude implementov´an vlastn´ım enginem aplikace. Abych zajistil, ˇze p´arov´an´ı pro ˇsv´ycarsk´y syst´em a jeho Baku akceleraci bude dle pravidel FIDE, bude implementov´ano extern´ım enginem JaVaFo. JaVaFo lze volat jako samostatn´y program nebo ho pouˇz´ıt jako Java knihovnu. Pouˇziji druhou moˇznost, jelikoˇz je to dle m´eho n´azoru jednoduˇsˇs´ı.
Jelikoˇz se v budoucnu bude nejsp´ıˇse uvaˇzovat o pˇrid´an´ı p´arovac´ıho enginu, byl tomu pˇrizp˚usoben n´avrh aplikace. Pro pˇrid´an´ı bude staˇcit pouze vytvoˇrit tˇr´ıdu implementuj´ıc´ı rozhran´ı PairingEngine a pˇridat do v´yˇctov´eho typu Pai-ringEngineId jeho identifik´ator. Na obr´azku 3.3 m˚uˇzeme vidˇet vˇsechny metody, kter´e mus´ı tˇr´ıda pˇredstavuj´ıc´ı p´arovac´ı engine implementovat. Jednoduˇse se jedn´a o metodu, kter´a vrac´ı seznam podporovan´ych turnajov´ych syst´em˚u. D´ale pak o dvˇe metody, kter´e provedou p´arov´an´ı pro turnaje jednotlivc˚u a druˇzstev.
Obˇe metody mohou vyhodit v´yjimku TournamentSystemNotSupportedExcep-tion, kter´a znamen´a, ˇze dan´y p´arovac´ı engine byl poˇz´ad´an o proveden´ı p´arov´an´ı pro turnajov´y syst´em, kter´y nepodporuje.
3.2.3 Datov´a vrstva
Datov´a vrstva m´a za ´ukol pˇredevˇs´ım perzistentnˇe ukl´adat data a tak´e je z to-hoto perzistentn´ıho prostˇred´ı z´ısk´avat. Kromˇe toho m´a za ´ukol implementaci logov´an´ı. Vyuˇz´ıv´a objektovˇe relaˇcn´ı mapov´an´ı JPA. Jednotliv´e entity jsou mapov´any na dan´e tabulky v relaˇcn´ı datab´azi. D´ıky t´eto vrstvˇe lze snadno vymˇenit relaˇcn´ı datab´azi za jinou. Pro aplikaci jsem zvolil datab´azov´y syst´em H2, jelikoˇz je jednoduch´y a m˚uˇze se pouˇz´ıt jako Java knihovna. Pro potˇreby aplikace je plnˇe dostaˇcuj´ıc´ı. CRUD operace s entitami jsou zpˇr´ıstupnˇeny pro business vrstvu pomoc´ı DAO rozhran´ı. D´ıky tomu je moˇzn´e pˇrej´ıt z relaˇcn´ıch datab´az´ı na jin´e perzistentn´ı prostˇred´ı, napˇr´ıklad na nerelaˇcn´ı datab´aze.
Nyn´ı pop´ıˇsi navrˇzenou strukturu datab´aze. Na obr´azku 3.4 m˚uˇzeme vidˇet relaˇcn´ı datov´y model. Jelikoˇz entity budou vyuˇz´ıvat dˇediˇcnost, musel jsem roz-hodnout, jak´ym zp˚usobem budou vypadat souvisej´ıc´ı tabulky. Potomci entity Tournament se liˇs´ı velmi m´alo, proto jsem se v tomto pˇr´ıpadˇe zvolit jednu ta-bulku pro oba potomky. To sam´e pak platilo pro entitu Round a jej´ı potomky.
Pro tˇr´ıdu Pairable jsem se rozhodl pro jin´y zp˚usob, jelikoˇz jej´ı potomci se
3.2. Architektura aplikace
Obr´azek 3.2: Hierarchie tˇr´ıd pˇredstavuj´ıc´ıch turnaj a jejich vztah s manaˇzerem