VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky. Systém pro foosballovou

VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky

S y s t é m p ro f o o s b a l l o v o u ligu Bakalářská práce

Autor: Jan Bouzek Vedoucí práce: PaedDr. František Smrčka, Ph.D. Jihlava 2011

Anotace Cílem této práce bylo vytvoření systému pro foosballovou (stolní fotbal) ligu. V úvodní části je seznámení s daným problémem, vymezení cílů a rešeršní studie existujících systémů. Další část popisuje analýzu a výsledný návrh modelované reality. Třetí část je věnována implementaci databáze a webové aplikace. Použité technologie jsou MySQL, HTML, CSS a skriptovací jazyky PHP a JavaScript. Poslední část zahrnuje výsledky z testování a srovnání aplikace s ostatními systémy tohoto typu. Klíčová slova Foosball liga, stolní fotbal, ITSF (International Table Soccer Federation), PHP, JavaScript, MySQL, HTML, CSS.

Annotation The aim of this work is to create a system of foosball (table soccer) league. The introductory section provides an introduction to the problem, the defininition of the objectives and the research studies of existing systems. The next section describes the analysis and final proposal modelled reality. The third part deals with the implementation of databases and web applications. The technologies used are MySQL, HTML, CSS and scripting languages PHP and JavaScript. The last section includes results of testing and a comparison with other application systems of this type. Keywords Foosball league, table soccer, (International Table Soccer Federation), PHP, JavaScript, MySQL, HTML, CSS.

Chtěl bych poděkovat svému vedoucímu práce PaedDr. Františku Smrčkovi, Ph.D. za jeho odbornou pomoc, kterou mi poskytl při vývoji aplikace a následném psaní bakalářské práce.

Prohlášení Prohlašuji, že předložená bakalářská práce je původní a zpracoval jsem ji samostatně. Prohlašuji, že citace použitých pramenů je úplná, že jsem v práci neporušil autorská práva (ve smyslu zákona č. 121/2000 Sb. o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů v platném znění, dále též „AZ“). Souhlasím s umístěním bakalářské práce v knihovně VŠPJ a s jejím užitím k výuce nebo k vlastní vnitřní potřebě VŠPJ . Byl jsem seznámen s tím, že na mou bakalářskou práci se plně vztahuje AZ, zejména § 60 (školní dílo). Beru na vědomí, že VŠPJ má právo na uzavření licenční smlouvy o užití mé bakalářské práce a prohlašuji, že s o u h l a s í m s případným užitím mé bakalářské práce (prodej, zapůjčení apod.). Jsem si vědom toho, že užít své bakalářské práce či poskytnout licenci k jejímu využití mohu jen se souhlasem VŠPJ, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených vysokou školou na vytvoření díla (až do jejich skutečné výše), z výdělku dosaženého v souvislosti s užitím díla či poskytnutím licence. V Jihlavě dne ...................................................... Podpis

Obsah 1

Úvod ......................................................................................................................... 7

2

Popis řešeného problému ....................................................................................... 9 2.1

Seznámení s daným problémem......................................................................... 9

2.2

Vymezení cílů .................................................................................................. 10

3

Rešeršní zpracování existujících implementací ................................................. 12

4

Použité technologie ............................................................................................... 14

5

6

7

8

4.1

HTML .............................................................................................................. 14

4.2

CSS................................................................................................................... 15

4.3

JavaScript ......................................................................................................... 15

4.4

PHP .................................................................................................................. 16

4.5

MySQL ............................................................................................................. 17

Analýza řešeného problému ................................................................................. 18 5.1

Úvodní studie ................................................................................................... 18

5.2

Datová analýza ................................................................................................. 20

5.3

Logický model ................................................................................................. 24

5.4

Výsledný návrh implementace databáze .......................................................... 28

Implementace ........................................................................................................ 29 6.1

Implementace databáze .................................................................................... 29

6.2

Tvorba rozhraní ................................................................................................ 31

6.3

Tvorba layoutu ................................................................................................. 40

6.4

Začlenění zdrojového kódu do layoutu ............................................................ 44

Testování ................................................................................................................ 45 7.1

Postup při testování .......................................................................................... 45

7.2

Problémy při testování ..................................................................................... 46

Závěr ...................................................................................................................... 47

Seznam obrázků ............................................................................................................48 Seznam použitých zkratek............................................................................................49 Literatura ......................................................................................................................50 Přílohy A

Uživatelský manuál

B

Obsah přiloženého CD

1 Úvod Téma mé bakalářské práce vychází z mého dlouholetého koníčku, kterým je stolní fotbal. Tento sport jsem začal provozovat již na základní škole. Po uplynutí několika let jsme s kamarádem dosáhli slušné úrovně a neměli v okolí soupeře. Totiž, v té době tato hra nebyla na Vysočině ještě příliš rozšířena. Když nás oslovil kamarád, který studoval v Praze a hrál tam foosballovou ligu, že chce v Jindřichově Hradci také založit ligu, zda se nepřidáme, neváhali jsme. Nápad to byl výborný, avšak jeho realizace už tak snadná nebyla. Byly stanoveny pouze velmi hrubé informace o tom, jak bude liga probíhat. Herní systém se převzal z Rosengart ligy, použila se pravidla ČFO (Česká foosballová organizace) a jako stůl byl stanoven Rosengart. To bylo ještě v pořádku a v té době ani lepší řešení nebylo. Založit ligu je ale o dost komplexnější záležitost než stanovit tyto tři věci. Tuto skutečnost vedení ligy opomnělo a výsledek byl jeden velký chaos. Nyní zde uvedu některé organizační nedostatky výše zmíněné ligy. První ročník byl opravdu velmi chaotický. Liga neměla žádné webové stránky ani jiné prostředky, potřebné pro zveřejnění výsledků, kontaktů a ostatních relevantních informací. Nikdo nevěděl, na které je pozici v žebříčku. Dalším problémem byla domluva mezi týmy na tom, kdy a kde uskuteční vzájemné utkání, poněvadž na sebe neměly kontakt. Druhý ročník ligy, již s novým vedením, byl o něco lepší. Byly vytvořeny statické webové stránky s kontakty osob a žebříčkem. Na konci každého utkání se vyplnila „listina ze zápasu“, kterou oba kapitáni podepsali. Tyto listiny se odevzdávaly jedné osobě, která ručně upravila výsledky v HTML stránce. To vedlo k častému zanesení chyby a následné ostré výměně názorů. Třetí ročník ligy již neproběhl. Proto jsem se rozhodl, že vytvořím přehlednou webovou aplikaci s databází, která bude členům ligy poskytovat rozdílné funkce dle jejich uživatelských rolí. Věřím, že bude již dostatečným zázemím pro zahájení nové sezóny. Jako databázi použiji MySQL, a to především proto, že se jedná o multiplatformní databázi, která je navíc volně šiřitelná. Není problém sehnat si levný či bezplatný webhosting podporující MySQL. Navíc mám s touto technologií zkušenosti. Pro programování dynamických webových stránek bude potřeba zvolit vhodný skriptovací jazyk, který navíc umí pracovat s MySQL. Rozhodl jsem se pro PHP. Je 7

volně šiřitelný a platformně nezávislý. Dále podporuje mnoho knihoven pro různé účely. Již v základní knihovně obsahuje rozsáhlý soubor funkcí (několik tisíc). Jeho velkou výhodou je obrovská podpora na hostingových službách a slušná dokumentace. Jako další skriptovací jazyk použiji JavaScript, který je vykonáván na rozdíl od PHP na straně klienta. Pro rozvržení struktury dokumentu použiji značkovací jazyk HTML. Výsledného vzhledu dokumentu dosáhnu použitím CSS (kaskádových stylů). Oddělení struktury a stylu je nejen přehlednější, ale také přináší snadnější strojové zpracování obsahu stránek. Navíc je to v dnešní době již standard. Mým cílem nebude vytvořit systém pro tak rozsáhlou ligu, jakou je např. Rosengart liga, která se hraje celostátně a dělí se dále do krajů. Zaměřím se spíše na menší ligy v jednom konkrétním kraji či lokalitě. Tyto ligy existují, ale spadají do nekomerční sféry. To je asi také důvod, proč pro svůj provoz využívají štosy papíru a v lepším případě statické webové stránky. Proto budu aplikaci vyvíjet tak, aby nebyla použitelná pouze na jednu konkrétní ligu, ale byla využitelná i pro ostatní foosballové ligy.

8

2 Popis řešeného problému 2.1 Seznámení s daným problémem Nejprve vysvětlím základní informace o této hře, potřebné k porozumění dalšího textu. Stolní fotbal, nebo také fotbálek či foosball, je hra pro čtyři hráče, případně pro dva nebo osm hráčů – to záleží na zvolené disciplíně. Hrací stůl má osm průchozích, nebo teleskopických tyčí, na kterých jsou v různém počtu umístěni panáčci. Princip foosball ligy je velmi podobný klasické fotbalové lize. Každý tým má registrováno své domácí hřiště (stůl). Může dokonce nastat situace, že jedno hřiště je registrováno více týmy, což vůbec nevadí. Tým si stanoví svého kapitána, který bude komunikovat s ostatními kapitány a vedením ligy. Dále má kapitán pravomoc potvrdit výsledky z odehraného zápasu. Systém zápasů je tzv. „každý s každým, doma i venku“, což znamená, že tým se utká postupně se všemi týmy ligy, a to dvakrát. Tedy jednou jako host a jednou jako domácí. Například v lize se třemi týmy každý tým odehraje čtyři zápasy. V lize se čtyřmi týmy každý tým odehraje dvanáct zápasů a v lize s pěti týmy každý tým odehraje již dvacet zápasů. Z tohoto poznatku odvodíme vzorec

kde

je počet zápasů, které musí tým odehrát, a

je počet týmů v lize.

Utkání se skládá z jednotlivých her. Hra se skládá z jednotlivých legů. Výsledky z utkání se evidují jako tzv. skóre, které se skládá ze dvou údajů: výsledky her, výsledky legů. Leg končí dosažením pěti branek. Jedna hra se skládá ze dvou vítězných legů (2:0 nebo 2:1). Utkání se skládá z jednotlivých her (např. šesti). Tedy skóre z jednoho utkání mezi dvěma týmy může vypadat třeba takto: hry 5:1, legy 10:4. Na konci utkání tým podle skóre získá: nula (prohra), jeden (remíza), tři (výhra) body, které se připíší do žebříčku (tabulka pořadí týmů). Utkání probíhá v souladu s oficiálními pravidly ITSF nebo ČFO. Pokud hráč během utkání provede nějaký prohřešek (technický faul), míč získává soupeř k trestnému střílení (penalta). Tyto prohřešky se neevidují. Dostatečným potrestáním je zmíněná penalta, která často skončí gólem. 9

2.2 Vymezení cílů Řešený problém byl již dostatečně popsán. Nastal tedy čas vymezit cíle, kterých je třeba dosáhnout pro vytvoření systému určeného k efektivnímu vedení ligy. Nejprve provedu krátkou rešeršní studii, abych zjistil, jak na tom ostatní foosballové ligy v ČR jsou, co se týče komputerizace jejich systémů. Dále se zaměřím na průběh těchto lig, jejich hlavní rysy, ustanovení a případné nedostatky. Krátce popíši technologie, které využiji pro vytvoření webové aplikace. Popis nebude obsahovat pouze stručnou specifikaci technologie, ale také některé zajímavé postřehy. Poté se začnu zabývat vývojem vlastní webové aplikace. Vývoj se bude skládat ze tří hlavních částí. Každé bude věnována jedna kapitola. První částí bude analýza řešeného problému, která se bude skládat z jednotlivých podkapitol: 

úvodní studie (souhrn hlavních systémových funkcí, kontextový diagram, atd.),



datová analýza (ERD),



logický model (relační model),



výsledný návrh implementace databáze.

Výsledkem této kapitoly bude dekompozice problému na dílčí části. Druhá část se bude věnovat implementaci. Zde bude popsáno vytvoření databáze a webového rozhraní. Webové rozhraní se bude skládat z rozhraní pro autorizované osoby (správce, rozhodčí, kapitán) a veřejně přístupného rozhraní. V rozhraní pro autorizované budou uživatelé moci provádět různé věci dle jejich oprávnění. Například vkládat a upravovat záznamy o osobách, týmech a hřištích. Dále vkládat aktuality a zobrazovat interní informace. Kapitáni týmů budou potvrzovat výsledky ze zápasů, vložené rozhodčím. Hlavní správce bude moci vygenerovat rozpis utkání, či nové přihlašovací údaje těm, kteří je zapomněli. Přihlašovací údaje budou dané osobě automaticky zasílány na email. Osoby si také mohou změnit přihlašovací údaje samy, po přihlášení. 10

V rozhraní pro neautorizované budou k vidění: informace o lize, informace o týmech, aktuality, pravidla, výsledky z utkání s žebříčkem, fotogalerie, kontakty na vedení ligy. Pro výsledný vzhled webu bude vytvořen vhodný layout (grafické rozvržení stránek). Třetí část vývoje aplikace se bude zabývat závěrečným testováním za účelem odhalení možných chyb. Do tohoto výzkumu zapojím nezávislou osobu, která o vnitřní struktuře systému nemá ponětí, ale má znalosti v oboru IT. To se hodí, jelikož snadněji a přesněji popíše případnou chybu. Po doladění případných chyb, odhalených testováním aplikace, napíši krátký manuál pro osoby pracující v autorizovaném rozhraní. Manuál bude uveden v příloze. V příloze dále uvedu obsah přiloženého CD. Výše jsem tedy přiblížil cíle, kterých chci dosáhnout, a stručnou posloupnost událostí, které k dosažení cílů povedou.

11

3 Rešeršní zpracování existujících implementací První zmínky o stolním fotbalu pocházejí z roku 1860. Ligové soutěže začaly vznikat v Německu a Belgii v roce 1950. Později se rozšířily i do USA, kde sklízejí obrovský úspěch. Informace týkající se foosballové ligy a foosballu obecně popisuje ve své knize Lott (1980). V České republice vzniká první liga až v roce 1999. Ve světě existuje mnoho velkých i malých lig, které ke svému fungování používají nejrůznější řešení. Bližší informace o těchto řešeních se nikterak nepublikují. Cestou, jak zjistit o fungování těchto lig alespoň něco, může být prozkoumání jejich webových stránek (pokud nějaké jsou). Hlavní zdroj informací je internet. V České republice můžeme definovat dva základní typy foosballové ligy. Pro svůj provoz používají rozdílná řešení, která závisí na velikosti dané ligy a jejích finančních prostředcích. Prvním typem je rozsáhlá foosballová liga, spadající do komerční oblasti, mající finanční prostředky z různých zdrojů. Druhým typem je malá lokální liga, zpravidla provozovaná několika nadšenci, nebo neziskovou organizací. Pojďme se tedy blíže podívat na jediného zástupce ligy typu – rozsáhlá, komerční. Tou je v České republice Rosengart foosballová liga. Zdroj informací o této lize je čerpán z webových stránek (http://www.foosball.cz/) a z rozhovorů s jejími členy. Byla zahájena 1. 5. 1999 nultým ročníkem a přihlášeno do ní bylo celkem šest týmů. V současné době se tato liga hraje v naprosté většině krajů České republiky a účastní se jí téměř 250 družstev. Je napojena na mezinárodní foosballovou federaci ITSF. Informace o této lize ve svém článku uvádí Souček (2007). Její herní systém je shodný s běžným, popsaným v druhé kapitole. Tento systém převzala ze západoevropských zemí, v nichž foosballová liga již desítky let probíhala. Zmiňuji se o tom, protože herní systém je základním kamenem při návrhu implementace systému pro řízení ligy. Nyní se zaměřím na způsoby, které stávající implementace využívá pro vkládání, zpracování a prezentaci dat. Dále na její hlavní rysy, které se dají z webových stránek (www.foosball.cz) a rozhovoru s jejími členy odvodit.

12

Systém takto rozsáhlé ligy je spravován několika osobami. Je poměrně komplexní a poskytuje mnoho informací. V každém kraji může paralelně probíhat více lig. To záleží na počtu přihlášených týmů v daném ročníku. Na webu této ligy nalezneme panel s hlavní nabídkou obsahující položky: Regiony, ČFO, FAQ, Ke stažení, Žebříčky, Turnaje, Termínovka, Diskuze. Dále je zde možnost přihlášení pro registrované uživatele nebo zobrazení mapy stránek pro snazší orientaci. Například v položce Regiony v hlavní nabídce nalezneme spoustu informací o konkrétním kraji (kontakty, zprávy z regionu, seznam probíhajících lig, turnaje, historii výsledků). Vše je poměrně přehledně uspořádáno. Přihlášení uživatelé mohou vkládat různé příspěvky a výsledky ze zápasů. Výsledky může vkládat kterýkoliv hráč. Kdyby nastala situace, že někdo nesouhlasí s vloženými výsledky, dá se skutečný výsledek zápasu ověřit. Na konci každého utkání se vyplní „listina ze zápasu,“ obsahující výsledky, kterou oba kapitáni podepíší. Ta se pak odešle správcům. Nevýhodou této ligy je bezesporu striktně daný hrací stůl Rosengart. Tomu nasvědčuje i fakt, že na stránkách této ligy v anketě „nejoblíbenější stůl“ nalezneme stůl Rosengart až na předposlední pozici. Nyní přejděme k ligám typu – lokální, nekomerční. Tento typ se vyznačuje především volností ve výběru stolu, menšími nebo žádnými finančními výdaji týmu. Systém určený k řízení ligy bývá zpravidla primitivní a zastaralý. Pro evidenci dat je v lepším případě použit tabulkový procesor (např. MS Excel). Pro prezentaci důležitých informací se používají statické webové stránky. Tyto stránky bývají často neaktuální. Jako zdroj informací jsem využil internet a rozhovory s členy těchto lig. Malé nekomerční ligy postrádají vhodný systém (web. aplikaci s databází), který by sloužil pro evidenci, zpracování a publikaci dat.

Takové systémy však znamenají

nemalé finanční náklady, které si malé ligy nemohou dovolit. V této studii je čerpáno pouze z jedné knihy, více jich o tomto sportu pravděpodobně nevyšlo. Dále jsem navštívil mnoho internetových stránek. Literatura, která by popisovala existující implementace systémů pro foosballové ligy, není k sehnání. Proto vycházím především z prozkoumání stránek těchto lig, svých dlouholetých zkušeností s tímto sportem a z rozhovorů s několika hráči, kteří ve výše uvedených ligách působí. 13

4 Použité technologie 4.1 HTML U klasických programovacích jazyků převládá strukturovaný text (programový kód) a obecný text se vyskytuje ve formě řetězců. U značkovacího jazyka naopak převládá obecný text, do kterého jsou vloženy strukturované úseky pomocí značek. Těmto jazykům, obzvláště pak HTML, se věnuje v části svých výukových materiálů věnovaných tvorbě webu Burget (2010). Různé značkovací jazyky se od sebe liší syntaxí a způsobem využití. Kromě jazyka HTML z rodiny SGML a jazyka XHTML z rodiny XML se často objevují jazyky zaměřené na počítačovou typografii: TeX (LaTeX) – tvorba publikací, Rich Text Format (RTF) – e1ektronické dokumenty. HyperText Markup Language je standardní jazyk pro tvorbu hypertextových dokumentů, který je spravován konsorciem W3C. HTML dokument, obvykle s příponou .html nebo .htm, může obsahovat text, vložené značky a znakové entity. Existují různá kódování češtiny: ISO-8859-2, CP1250, UTF-8. Na začátku dokumentu je zvláštní značka !DOCTYPE , za kterou se uvede specifikace dokumentu. Tato specifikace mimo jiné určí vykreslovací režim (mód) prohlížeče a další vlastnosti. Rozhodně by neměla být vynechána. Struktura dokumentu se skládá z hlavičky a těla dokumentu. Původně HTML sloužilo ke specifikaci vizuální prezentace společně s obsahem. To bylo velmi nepřehledné a při úpravě vzhledu celého webu se musely změnit všechny dokumenty. Řešením bylo odebrat prostředky pro definici vzhledu z HTML a vytvořit oddělené prostředky pro definici vzhledu CSS. Značné zlepšení přináší verze HTML 4.01. Ještě lépe na tom je XHTML a HTML 5.0. Je však nutné zachovat zpětnou kompatibilitu.

14

4.2 CSS Kaskádové styly definují vzhled dokumentu nezávisle na obsahu. Vzhled může být definován odděleně, což činí HTML kód přehlednější. Další výhodou je konzistentnost vzhledu webu a jeho snadná modifikace. Kaskádové styly popsal Burget (2010). Stylesheet (stylový předpis) je souhrn pravidel, která určují vizuální vlastnosti jednotlivých elementů HTML kódu. Dokument je popsán stylesheety ze tří zdrojů, které se seřadí do kaskády a určí výsledný vzhled dokumentu. Tyto tři stylesheety jsou: 

styl definovaný tvůrcem stránek,



uživatelský styl,



styl prohlížeče.

Selektor slouží k určení elementu, na který se definované vlastnosti použijí. Jednotlivé vlastnosti se definují ve tvaru vlastnost: hodnota; a každá vlastnost má své jméno. Pro každou vlastnost jsou definovány možné hodnoty. Kaskádové styly definují mnoho různých selektorů, které jdou obvykle kombinovat. Hodnoty některých vlastností se dědí na potomky. Vlastnosti elementů lze dynamicky měnit pomocí JavaScriptu. Kaskádové styly obsahují mnoho dalších vlastností pro formátování dokumentu, navíc se mohou uložit do cache paměti a tím zrychlit vykreslování jednotlivých stránek. Styl lze deklarovat v hlavičce. To není příliš výhodné, protože se musí definovat v každém dokumentu, což přináší pracné udržování konzistence webu. Externí stylesheet je proto výhodnější. V hlavičce ho pouze krátkým příkazem připojíme k dokumentu. Takových externích CSS souborů můžeme připojit i více. Také lze použít inline styly, které se uvádějí bez selektoru, přímo v daném elementu HTML.

4.3 JavaScript Je skriptovací jazyk sloužící k zápisu programu, který je interpretován prohlížečem na straně klienta. JavaScript popisuje Burget (2010). Tento jazyk vychází z jazyků C a Java. Je objektově orientovaný a rozlišuje velká a malá písmena (case sensitive). Mírná nekompatibilita je způsobena tím, že zatím každý prohlížeč používá rozdílné API.

15

JavaScript se používá na: 

generování dynamického obsahu (vložení času, reakce na verzi prohlížeče, atd.),



interaktivní práci s dokumentem (reakce na pohyb myši, změna vzhledu dokumentu, atd.),



ovládání prohlížeče.

Skript můžeme přímo vložit do dokumentu, nebo se na externí skript odkázat v hlavičce dokumentu. Vykonává se až poté, co na něj prohlížeč narazí. Kde je to možné, použije se automatická konverze typů. Aplikační rozhraní ve webových prohlížečích definuje existující objekty. Objekt má své vlastnosti (atributy) a metody. Vlastnostem můžeme přiřazovat hodnoty nebo je číst. Metody lze volit a mohou vracet hodnotu. Základními prvky prohlížeče jsou: obecné prvky jazyka (String, Date, Math), objekty prohlížeče (window – okno prohlížeče, další vnořené objekty), model dokumentu (document – dokument jako celek, element – element HTML kódu).

4.4 PHP PHP je skriptovací jazyk určený především k tvorbě dynamického webu. Technologií na vytvoření dynamického webu je mnoho. Jedná se buďto o „klientské“ technologie (JavaScript), u kterých je programový kód vykonáván na straně klienta, nebo se jedná o „serverové“ technologie (PHP), u nichž je programový kód zpracováván na serveru. PHP kód je začleněn přímo do HTML kódu. Webový server kód PHP zpracuje a vygeneruje HTML dokument. Tedy klient nevidí programový kód PHP, pouze serverem sestavený HTML dokument. Syntaxe PHP je inspirována několika jazyky (Perl, C, Pascal, Java). Jazyk je multiplatformní a je šířen pod PHP licencí. Jedná se o Open Source licenci. Je zakázáno používat názvu a loga PHP bez povolení od The PHP Group (tzv. copyleft). Tuto licenci vydalo The PHP Group (2010). Charakteristické vlastnosti a použití tohoto jazyka výstižně popisuje Bell (2003). PHP disponuje rozsáhlým souborem funkcí, a to již v základní knihovně. Navíc podporuje mnoho knihoven pro nejrůznější účely jako: zpracování textu, grafiky, práce se soubory, přístup k většině databázových systémů. 16

Pro tvorbu webových aplikací je často využívána tzv. LAMP technologie (spojení OS Linux, web. serveru Apache, databázového systému MySQL a jazyka PHP či Perl). Jazyk PHP je dynamicky typový (určení typu proměnné v okamžiku přiřazení). Jeho pole jsou heterogenní (jedno pole může obsahovat prvky různých typů). Základy objektově orientovaného programování (OOP) byly přidány ve verzi PHP 3. Ve verzi PHP 5 bylo OOP značně předěláno a rozšířeno.

4.5 MySQL Jedná se o databázový systém, který je multiplatformní a je k dispozici jak pod volnou licencí GPL, tak pod komerční licencí. Jak již název napovídá, komunikace s databází probíhá pomocí SQL jazyka (neprocedurální jazyk, používaný pro práci s daty v relačních databázích). MySQL je poměrně rychlý systém, který donedávna nepodporoval triggery, pohledy, uložené procedury a další. Tyto nevýhody jsou každou novou verzí eliminovány, obzvláště pak u placených verzí. Když se klient připojí k serveru, dostane vlastní vlákno. Nejprve se provede rozbor dotazu, po kterém je vykonána optimalizace. Pomocí klíčových slov programátor optimalizátorů předává pokyny (hints). MySQL má několik úložných enginů (úložiště dat), které se liší možnostmi použití a uložení dat. Pokud jste například chtěli použít v některém schématu cizí klíče, tabulky musely být v úložišti InnoDB.

17

5 Analýza řešeného problému 5.1 Úvodní studie Jedná se o důležitou součást vývoje systému, která je základem pro další fáze vývoje. Někteří informatici ji nedoporučují a raději preferují rozsáhlejší předprojektovou přípravu. Úvodní studii, především pak kontextovou analýzu, popisuje Mišovič (2009).

5.1.1 Specifikace funkcionality systému Nejprve je třeba uvést specifikace na funkcionalitu systému. Celý systém řídí hlavní správce. Ten má nejvyšší oprávnění. Může vkládat, upravovat a mazat evidovaná data. Běžný správce má pouze pravomoc vkládat evidovaná data. Evidují se informace o zápasech, týmech, hráčích, hřištích, rozhodčích a správcích. Každý tým je tvořen hráči. Hráči si určí kapitána, který obdrží přihlašovací údaje k autorizovanému rozhraní aplikace. Ten bude za tým provádět úkony jako: potvrzení výsledků ze zápasu, vkládání příspěvků, komunikace s ostatními osobami formou emailu. Tým si musí zvolit své domácí hřiště, které bude ze seznamu schválených stolů. Může nastat situace, že více týmů používá jedno hřiště, což nevadí. Rozhodčí soudí zápas. Poté pomocí formuláře zadá výsledky do systému. Výsledky, které již potvrdili oba kapitáni, se započtou. Započtené výsledky jsou rozumnou formou prezentovány. Kapitáni, rozhodčí a správci po registraci (provedenou správcem) obdrží přihlašovací údaje (login, heslo). Tyto údaje si budou moci sami změnit. V případě, že údaje zapomenou, kontaktují hlavního správce, který jim vygeneruje nové údaje. Dále tyto osoby budou moci vkládat příspěvky a budou mít přístup k interním údajům. Veřejně přístupné rozhraní bude poskytovat: informace o lize, informace o týmech, fotky, pravidla, kontakty, atd.

5.1.2 Kontextová analýza Nyní nastává čas na kontextovou analýzu ligy. Na nejvyšší úrovni pohledu na ligu se definuje její okolí. Poté se stanoví tok informací mezi ligou a okolím. Vytvoří se 18

diagram nazývaný „kontextový diagram 1. přiblížení“ (KD1).

V tomto diagramu

pohlížíme na ligu jako na nedělitelný celek – „černou skřínku“. Vidíme, jaké informace do ní („černé skřínky“) z okolí vstupují a také jaké informace z ní do okolí vystupují.

Obrázek 1: Kontextový diagram 1. přiblížení

Výše uvedený diagram ještě není dostatečně podrobný pro modelování datových závislostí a procesů. Je třeba rozložit ligu na dílčí celky. Po rozkladu musíme toky z vyšší úrovně rozdělit mezi toky z nižší úrovně (konsolidace toků). V našem případě nemá smysl členit ligu na podsystémy. Uzavřený celek ligy nahradíme pouze význačnými místy a „kontextový diagram druhého přiblížení“ (KD2) dostává následující tvar (viz další strana). Nyní můžeme postoupit k datové analýze.

19

Obrázek 2: Kontextový diagram 2. přiblížení

5.2 Datová analýza Při nacházení entit, jejich atributů a hledání vztahů mezi entitami se vychází z popisu aktivit (specifikace systému) od zadavatele a z úvodní studie. Výsledný datový model (ERD) by měl zadavatel schválit. Jelikož je v tomto případě zadavatel a analytik jedna a ta samá osoba, bude tento požadavek splněn. Postup při datové analýze a tvorbě datového modelu popisuje Mišovič (2009). Hráč, rozhodčí, správce a hlavní správce mají jistě mnoho společných atributů, proto zavede ISA hierarchii osoba (analogie dědičnosti v OOP). Atributy budou: id, jméno, příjmení, přihlašovací údaje. „Id“ bude identifikačním klíčem entity. Podtyp hráč bude mít navíc atribut kapitán. Podtyp rozhodčí a správce další atributy zatím nemají. Pro hlavního správce nebudeme zavádět další podtyp, rozlišíme ho podle hodnoty atributu id. Další objevenou entitou je tým. Její identifikační klíč bude „název“ týmu. Hráč je členem týmu. Tedy entity hráč a tým mají spolu vztah. Nazvěme ho „je členem“. Tým se může skládat z více hráčů. Hráč může být členem právě v jednom týmu. Tedy kardinalita (poměr) vztahu tým:hráč je 1:N. Nyní stanovme parcialitu (členství) vztahu.

20

Hráč má povinné členství ve vztahu (musí patřit do nějakého týmu). Tým má členství ve vztahu nepovinné (tým může existovat i bez hráčů). Každý tým musí vlastnit domácí hřiště. Hřiště je tedy další entitou, která je ve vztahu s entitou tým. Tento vztah nazvěme „vlastní“. Tým musí vlastnit právě jedno hřiště. Jedno hřiště může být vlastněno žádným, jedním nebo několika týmy. Kardinalita vztahu hřiště:tým je 1:N. Tým má povinné členství ve vztahu. Hřiště má nepovinné členství ve vztahu. Tým je identifikován klíčovým atributem „id“. Týmy mezi sebou hrají zápasy. Zápas je další entitou, která je ve vztahu s entitou tým. Tento vztah nazvěme „hraje“. Zápas má identifikační klíč „id“. Tým může hrát jeden, žádný nebo několik zápasů. Zápas je hrán žádným nebo několika (dvěma) týmy. Tedy parcialita obou entit ve vztahu je nepovinná. Kardinalita je M:N. Vazba M:N je problematická, proto ji rozdělíme do dvou vztahů typu 1:N, N:1 – dekompozice. Dekompozice je znázorněna na obrázcích níže.

Obrázek 3: Vztah M:N před dekompozicí

Obrázek 4: Dekomponovaný vztah M:N na vztahy 1:N, N:1

Entita „rozpis“ je slabý entitní typ. Tedy není jednoznačně identifikována pouze pomocí svých atributů, ale také pomocí atributů „název“ týmu a „id“ zápasu. Pokud by nebyl atribut „doma“ klíčový, dva stejné týmy by spolu mohly odehrát pouze jeden zápas. Jelikož spolu mají odehrát dva zápasy (každý tým bude hrát jednou doma a jednou venku), musí být atribut „doma“ klíčový. Přidáním atributu „doma“ do identifikačního klíče entity „rozpis“ zajistíme, že dva společné zápasy budou rozlišeny.

21

Každý zápas soudí rozhodčí. Vztah mezi entitou zápas a entitou rozhodčí můžeme pojmenovat „soudí“. Zápas soudí právě jeden rozhodčí. Rozhodčí může soudit žádný, jeden nebo několik zápasů. Kardinalita vztahu rozhodčí:zápas je 1:N. Entita zápas má povinné členství ve vztahu. Entita rozhodčí nemá povinné členství ve vztahu. Může se zdát, že entita „správce“ neparticipuje ve vztazích. Tedy je zbytečné ji v diagramu uvádět. Opak je pravdou. Tato entita participuje v mnoha vztazích. Hledíme však na problém z jiné úrovně pohledu. V ERD diagramu (viz další strana) se objevují atributy „adresa“ a „skóre“, které nejsou atomické, ale tzv. skupinové atributy. To znamená, že jsou to strukturované datové typy. Atribut adresa se skládá z: ulice, čísla, města. Atribut skóre se skládá z: hry, legy.

22

23

Obrázek 5: ERD diagram pro foosballovou ligu

5.3 Logický model V této podkapitole budeme transformovat ER model do relačního modelu dat (RMD). Touto problematikou se ve svých skriptech zabývá Bureš (2009). Tento model má oproti konceptuálnímu modelu nižší úroveň abstrakce. Zabývá se logickými strukturami, v nichž jsou data uložena. Nezabývá se však jejich implementací. Ta již spadá do fyzického modelu, který má ještě nižší úroveň abstrakce.

5.3.1 Seznámení s relacemi Pro manipulaci s daty se používají tyto prostředky: relační algebra, relační kalkul. Relaci si můžeme zjednodušeně představit jako tabulku s konečným počtem prvků. Relace nemůže obsahovat duplicity a prvky v ní nejsou uspořádány. Uveďme souvislosti mezi relací a entitou: schéma relace ~ entitní typ, prvek relace (n-tice) ~ výskyt entity, prvek n-tice ~ atribut entity. Souvislost tabulky a entity je následující: tabulka ~ entitní typ, řádek tabulky ~ výskyt entity, sloupec tabulky ~ atribut entity.

5.3.2 Transformace ER modelu do RMD Silným entitním typům bude odpovídat schéma relace. Primárním klíčem zde bude identifikační klíč entitního typu. Skupinové atributy musíme rozložit. RMD by měl obsahovat pouze atomické atributy.

Obrázek 6: Vztah mezi entitami hráč – tým

U vztahu 1:N hraje roli pouze parcialita determinantu. Na obr. 6 je determinantem vztahu „hráč“. Zde je členství determinantu povinné (hráč je členem právě v jednom týmu). V takovém případě přilepíme atribut „název“ k relaci „hráč“ (k determinantu). hráč (id, …, název)

tým (název, …)

24

Obrázek 7: Vztah mezi entitami tým – hřiště

Zde je determinantem vztahu „tým“ (viz obr. 7). Jeho členství je povinné. Tedy přilepíme atribut „id“ k relaci „tým“. tým (název, …, id)

hřiště (id, …)

_____________________________________________________________________________

Obrázek 8: Vztah mezi entitami zápas – rozhodčí

Zde je determinantem vztahu „zápas“ (viz obr. 8). Jeho členství je povinné. Tedy přilepíme atribut „id“ rozhodčího k relaci „zápas“. zápas (id, …, id_rozhod)

rozhodčí (id, …)

_____________________________________________________________________________

Obrázek 9: Vztah mezi entitami tým – zápas

U vztahu M:N budou tři relace (viz obr. 9). Primárním klíčem vztahové relace budou příslušné cizí klíče a klíčový atribut „doma“ – viz obrázek 4. tým (název, …)

zápas (id, …)

rozpis (název_týmu, id_zápasu, doma)

Dále je potřeba transformovat ISA hierarchii. Jsou tři možné způsoby: 

jediná relace se všemi atributy nadtypu i všech podtypů plus atribut, jakého typu entita je (rozhodčí, správce, hráč) – vzniká mnoho prázdných hodnot 25



relace pro entitní podtypy – v každé relaci atributy nadtypu



relace pro každý typ – nadtyp i podtyp.

Obrázek 10: ISA hierarchie

Pro entitu hráč, která navíc po transformaci získá atribut „název týmu“, použijeme druhou možnost transformace z výše zmíněných. Tedy výsledná relace obsáhne atributy nadtypu. Pro entity rozhodčí a správce zavedeme jedinou relaci, která bude obsahovat všechny atributy nadtypu (podtyp žádné nemá) plus atribut, jakého typu entita je (správce, rozhodčí). Nyní uvedeme výsledné relace s kompletním popisem jejich atributů. Dále zde uvedeme některá integritní omezení, která zajistí, aby relace obsahovala pouze správná data. Také zkontrolujeme normální formy (NF). Primární klíč musí být unikátní a nenulový, značíme ho podtržený. Integritní omezení zajistíme na straně databáze (deklarativní). To pro koncového uživatele nestačí. Zajistíme ještě kontrolu procedurálně přímo v kódu. Kontrola NF slouží k tomu, aby schéma relace splňovalo jisté požadavky (malá redundance, odstranění aktualizačních anomálií). hrac (id, prijmeni, jmeno, email, login, heslo, nazev_tymu, kapitan) 

nazev_tymu je cizí klíč z relace tym (FOREIGN KEY)



všechny prvky n-tice musí být neprázdné (NOT NULL)



prvky email a login musí být unikátní (UNIQUE)

26

hriste (id, typ, ulice, c_p, mesto, popis, mince) 

kromě prvku popis musí být všechny prvky neprázdné

osoba (id, prijmeni, jmeno, email, login, heslo, spravce, rozhodci) 

všechny prvky musí být neprázdné



prvky email a login musí být unikátní

rozpis (nazev_tymu, id_zapasu, doma) 

prvky nazev_tymu a id_zapasu jsou cizí klíče z relací tym a zapas

tym (nazev, body, vyhry, prohry, remizy, suma_hry, suma_legy, id_hriste, odehrane) 

id_hriste je cizí klíč z relace hriste



všechny prvky musí být neprázdné

zapas (id, hra_D, hra_H, leg_D, leg_H, kap_d, kap_h, zapocteno, id_rozh) 

id_rozh je cizí klíč z relace osoba



všechny prvky musí být neprázdné

5.3.3 Kontrola normálních forem První normální forma je splněna, pokud každý prvek n-tice (atribut) je elementární a nestrukturovaný. To jsme již zajistili rozkladem skupinových atributů. Druhá normální forma je splněna, pokud neexistuje závislost atributů na podmnožině žádného klíče. V našem případě jsou všechny klíče až na relaci „rozpis“ jednoprvkové. Tedy zbývá prozkoumat relaci „rozpis“. Ta výše uvedené pravidlo splňuje. Třetí normální forma je splněna, pokud žádný neklíčový atribut není tranzitivně závislý na žádném klíči. Tuto podmínku nesplňují relace: hráč, osoba. V obou relacích je tranzitivní závislost ostatních atributů na klíči přes „login“ nebo „email“. Tyto dva atributy mají integritní omezení (NOT NULL, UNIQUE). Oba jsou adepti na klíč. Místo nich byl zvolen uměle vytvořený klíč „id“. Bude se s ním praktičtěji pracovat. Možným řešením by bylo udělat další relace. Tuto drobnou redundanci budeme však tolerovat a nové relace zavádět nebudeme. 27

Obrázek 11: EER diagram pro foosballovou ligu

5.4 Výsledný návrh implementace databáze

28

6 Implementace V této kapitole bude shrnut postup při implementaci jednotlivých částí systému. Nejprve bude přiblížena implementace databáze. Poté bude popsána implementace webové aplikace, která se bude skládat z několika částí.

6.1 Implementace databáze Pomocí nástroje phpMyAdmin se vytvoří tabulky dle EER diagramu (viz obr. 11). Jako úložiště je zvoleno „InnoDB“, jelikož podporuje cizí klíče. Znaková sada je zvolena UTF-8. Kolace (způsob řazení) je zvolena „utf8_general_ci“ (zkratka ci = case insensitiv), nerozlišuje velikost písmen a je univerzální pro více jazyků. To znamená, že například písmeno „ch“ bude bráno jako dvojice písmen „c“ a „h“. Jelikož bude ukládaný text česky i anglicky, je „utf8_general_ci“ správnou volbou. Problematika češtiny v MySQL je zevrubně popsána v článku, jehož autorem je Málek (2007). Tabulky: hřiště, hráč, osoba, zápas používají jako primární klíč identifikační číslo „id“. Tento sloupec tabulky nastavíme tak, aby se při vložení dalšího záznamu jeho hodnota automaticky zvyšovala (auto_increment). Dále je třeba vložit SQL příkazem „alter table,“ cizí klíče. Na EER diagramu (viz obr. 11) si všimněme, že křivky a přímky, jež spojují tabulky a znázorňují propojení tabulek cizími klíči, jsou kresleny přerušovaně nebo nepřerušovaně. Nepřerušovaně jsou kresleny ty, u nichž cizí klíč zároveň identifikuje tabulku a je součástí primárního klíče (viz tabulka „rozpis“). Přerušovaně jsou kresleny ty, u nichž cizí klíč není součástí primárního klíče. Nyní si uvedeme, jak by se SQL příkazem „create table“ vytvořila tabulka „zápas“. CREATE TABLE IF NOT EXISTS `zapas` ( `id` int(11) NOT NULL auto_increment, `hra_D` int(11) NOT NULL default '0', `hra_H` int(11) NOT NULL default '0', `leg_D` int(11) NOT NULL default '0', `leg_H` int(11) NOT NULL default '0', `kap_d` int(11) NOT NULL default '0', `kap_h` int(11) NOT NULL default '0',

29

`zapocteno` int(11) NOT NULL default '0', `id_rozh` int(11) NOT NULL, PRIMARY KEY

(`id`),

KEY `id_rozh` (`id_rozh`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

Jelikož datový typ BOOL nebo jemu podobné nebývají vždy podporovány, proto u sloupců: „kap_d, kap_h, zapocteno“, které by měly být typu BOOL a nabývat hodnot: true, false, zvolíme typ INTEGER (tedy true ~ 1, false ~ 0). Nyní ukažme, jak by se do tabulky „zápas“ vložil příslušný cizí klíč „id_rozhodčího“ z tabulky „osoba“. ALTER TABLE `zapas` ADD CONSTRAINT `zapas_ibfk_1` FOREIGN KEY (`id_rozh`) REFERENCES `osoba` (`id`) ON DELETE CASCADE ON UPDATE CASCADE;

Poslední řádek kódu znamená, že odkazovaný záznam se smaže nebo přepíše aktualizovanou hodnotou. Ukažme nyní tabulku „rozpis“, která má cizí klíče jako součást primárního klíče. CREATE TABLE IF NOT EXISTS `rozpis` ( `nazev_tymu` varchar(30) NOT NULL, `id_zapasu` int(11) NOT NULL, `doma` int(11) NOT NULL, PRIMARY KEY

(`nazev_tymu`,`id_zapasu`,`doma`),

KEY `id_zapasu` (`id_zapasu`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; ALTER TABLE `rozpis` ADD CONSTRAINT `rozpis_ibfk_1` FOREIGN KEY (`nazev_tymu`) REFERENCES `tym` (`nazev`) ON DELETE CASCADE ON UPDATE CASCADE, ADD CONSTRAINT `rozpis_ibfk_2` FOREIGN KEY (`id_zapasu`) REFERENCES `zapas` (`id`) ON DELETE CASCADE ON UPDATE CASCADE;

U tvorby ostatních tabulek se postupuje podobně. Nebudou zde proto uvedeny, ale na přiloženém CD bude kompletní SQL skript, pomocí něhož může být databáze vytvořena a na nějž se můžete podívat.

30

6.2 Tvorba rozhraní Aplikace obsahuje dva typy rozhraní: neautorizované (veřejně přístupné), autorizované (pro přihlášené). Nejprve začneme autorizovaným rozhraním.

6.2.1 Autorizace a ověření uživatele Autorizované rozhraní umožňuje rozdílné funkce, které vycházejí z uživatelských rolí (správce, hlavní správce, kapitán, rozhodčí). Při přihlášení uživatel volí jednu ze tří možností (správce – tato volba i pro hlavního správce, rozhodčí, kapitán) a zadá své login a heslo. Pokud chce přihlášený změnit svou uživatelskou roli, musí se odhlásit a znovu přihlásit. Tento způsob je bezpečnější, ale hlavní důvod je ten, že kapitán je uložen v jiné tabulce než rozhodčí a správce. V těchto dvou tabulkách může mít osoba rozdílné přihlašovací údaje a pravděpodobně i rozdílné „id“, které po přihlášení slouží k identifikaci uživatele. Proto je způsob přihlašování řešen takto jednoduše. Může se zdát poněkud triviální, ale z výše popsaných důvodu je rozumným řešením. Při autorizaci jsou porovnány přihlašovací údaje s údaji v databázi. Pokud je vše v pořádku, do session proměnných uložíme „id“ a „roli (funkci)“ uživatele. Každá zabezpečená část obsahuje nejprve krátkou funkci, která dle session proměnných zjistí, zda má uživatel povolen přístup. Pokud ne, je okamžitě přesměrován do přihlašovací sekce. Takto je tedy řešeno ověření uživatele. Ochrana proti „podstrčení“ údajů do formuláře a následně do databáze bude vysvětlena na konkrétním případě později.

6.2.2 Hlavní správce Hlavní správce je pouze jeden. Přihlašuje se jako běžný správce. Od běžného správce je rozeznán pomocí atributu „id“, který má hodnotu jedna (id=1). function prihlasen() { if (($_SESSION['idS']==1) && ($_SESSION['funkceS']==s)) return true; else return false; }

Hlavní správce může provádět mnoho věcí (registrace, editace, přidělování nových přihlašovacích údajů, generování rozpisu a další). Pojďme si jeho možnosti přiblížit. 31

6.2.2.1 Registrace Uveďme zde scénář, jak se musí postupovat při registraci. Nelze začít registrovat nejprve hráče, jelikož musíte ve formuláři vybrat název jeho týmu, který zatím není k dispozici. Pokud tak neučiníte, budete upozorněni a registrace se nevykoná. Při registraci týmu musí být vybráno domácí hřiště. Tedy správný postup je: registrace hřiště, registrace týmu, registrace hráčů. Dále je možno registrovat rozhodčí a správce. Registrace správců není nutná. Registrace rozhodčího musí proběhnout, než bude hlavní správce v sekci „Inicializace“ inicializovat zápasy a rozpis. Všechny formuláře jsou ošetřeny. Pokud zadáte nevyplněný nebo špatně vyplněný údaj a formulář odešlete, budete upozorněni a transakce se neprovede. Formuláře jsou kontrolovány pomocí regulárních výrazů (např. email, číslo). U sloupců login a email, které jsou unikátní, je testována jejich přítomnost v databázi. Dále kontrolujeme, zda určité řetězce nejsou příliš krátké, či dlouhé (např. příjmení musí mít 2 až 20 znaků). Při registraci hráče a zaškrtnutí položky „kapitán“ kontrolujeme, zda daný tým již jednoho kapitána nemá. Kontroluje se ještě mnoho dalších věcí. function emailvdb ($email) { $vysledek=mysql_query("select * from hrac where email='$email'"); return (boolean) mysql_num_rows($vysledek); } if (emailvdb($_POST["email"])) echo "Uvedený email již existuje.";

Všechny údaje, u kterých není napsáno „nepovinné“, musí být vyplněny. Nepovinné údaje jsou v celé aplikaci pouze dva. Tedy nemá smysl u každého údaje zbytečně uvádět „povinné“, což by jen narušovalo přehlednost a vzhled. Navíc se nejedná o jednorázovou činnost (jako třeba registrace emailové schránky), ale činnost, která bude prováděna opakovaně. Pokud budete po odeslání upozorněni na chybějící nebo špatně zadané údaje, dříve vyplněné údaje se neztratí. Pokud registrujete kapitána, správce nebo rozhodčího, heslo se mu vygeneruje automaticky. Spolu s loginem se odešle registrovanému na jeho email, který během registrace vyplníte. Před odesláním emailu je třeba zajistit, aby byla ve zprávě správně zobrazena čeština. Na to použijeme RFC 2047, který je jeden ze šestice dokumentů definovaných internetovým standardem MIME. 32

//Zakódování e-mailové hlavičky dle RFC 2047 function mime_header_encode($text, $encoding = "utf-8") { return "=?$encoding?Q?" . imap_8bit($text) . }

Do databáze se ukládá otisk hesla fixní délky, který získáme hešovací funkcí MD5. $hesloMD5 = MD5($heslo);

//otisk hesla

6.2.2.2 Editace Pokud vyberete v hlavní nabídce editaci, můžete mazat a upravovat: hráče, týmy, hřiště, rozhodčí a správce. Po vybrání jedné z možností (např. hráče) se vám zobrazí seznam všech evidovaných. U hráčů, rozhodčích a správců můžete tento seznam upřesnit (viz obrázek 12). U seznamů týmů a hřišť nelze řádky filtrovat. Jsou pouze seřazeny. Vzhledem k tomu, že liga bude v reálu obsahovat maximálně 15 týmů (jinak by se muselo hrát moc zápasů), seznam týmů a hřišť je opravdu zbytečné filtrovat.

Obrázek 12: Ukázka editace hráče

33

Poslední dva sloupce seznamů vždy obsahují odkazy: upravit, smazat. Po kliknutí na odkaz „smazat“ je záznam v databázi, odpovídající řádku v seznamu, smazán. Pokud budete chtít smazat hřiště, které je domácím hřištěm nějakého týmu, akce se neprovede a budete upozorněni (smazání by vedlo ke smazání týmu i jeho hráčů). V takovém případě musíte nejprve změnit týmu domácí hřiště. Ke změnám evidovaných dat slouží odkaz „upravit“. Po kliknutí na tento odkaz (viz obr. 12) se vám objeví podobný formulář jako při registraci. Rozdíl je v tom, že se do formuláře načtou stávající informace o zvoleném řádku z databáze, což je velmi pohodlné a přehledné. Nelze zde měnit „login“ uživatelů (viz další podkapitola). 6.2.2.3 Přihlašovací údaje Každý uživatel si může po přihlášení změnit heslo. Pokud se ale nemůže z nějakého důvodu (např. zapomenuté heslo) přihlásit, napíše hlavnímu správci (kontakt na něj je ve veřejném rozhraní). Ten v sekci „Přihlašovací údaje“ zvolí možnost „hráč“ nebo „správce a rozhodčí“. Objeví se mu příslušný seznam uživatelů, který může filtrovat. Po nalezení uživatele v seznamu klikne na odkaz „upravit“. Zobrazí se formulář s položkami: jméno, příjmení, login. První dvě položky jsou uzamknuty. Hlavní správce může upravit login (není však podmínkou). Po odeslání formuláře tlačítkem „vygeneruj“ se uživateli vygeneruje nové heslo, které mu spolu s loginem přijde automaticky emailem (viz ukázka zdrojového kódu). Přihlašovací údaje si může po přihlášení změnit. $heslo = Random_Password(8);

//nove osmimistne heslo

mail( mime_header_encode($jmeno.' '.$prijmeni) . " <$email>", "Foosball league", "Dobrý den,\r\n\r\n níže jsou vaše nové přihlašovací údaje do FOOSBALL Ligy. \r\n\r\n login: $login \r\n heslo: $heslo ", "MIME-Version: 1.0\nContent-Type: text/plain; charset=utf8\nContent-Transfer-Encoding: 8bit" );

34

6.2.2.4 Inicializace V části inicializace, kterou také naleznete v nabídce hlavního správce, máte na výběr ze dvou možností: vygenerovat zápasy, vygenerovat rozpis zápasů. Nejprve musíte zvolit první možnost. Než zvolíte první možnost, musí být registrován alespoň jeden rozhodčí a alespoň dva týmy. Pokud tyto podmínky nebudete respektovat, akce se neprovede a objeví se odpovídající upozornění. Vygenerování zápasů probíhá tedy tak, že nejprve se zjistí počet týmů a rozhodčích. Pokud není splněna podmínka (alespoň dva týmy a jeden rozhodčí), vypíše se upozornění a skript je ukončen. Pokud je podmínka splněna, nic nebrání ve vygenerování zápasů. Vše probíhá automaticky. Podle počtu týmů se vygeneruje odpovídající počet zápasů (viz ukázka zdrojového kódu). $poc_zap=($poc_tym * $poc_tym) - $poc_tym;

//vypocitame pocet zapasu

for($i=1;$i<=$poc_zap;$i++) { $index=($i % $poc_roz);

//index pro pole s čísli rozhodčích

$id_roz=$rozhod[$index]; $query = @MySQL_Query("INSERT INTO zapas VALUES ('$i', '0', '0', '0', '0', '0', '0', '0', '$id_roz')"); }

Jak je z ukázky zdrojového kódu zřejmé, nejprve do proměnné: $poc_zap přiřadíme vypočtený počet zápasů ($poc_roz určuje počet rozhodčích, $poc_tym určuje počet týmů). Poté uvnitř cyklu nastavíme proměnné: $index, $id_roz a vložíme nový řádek do tabulky „zápas“. Proměnná: $i je řídící proměnnou cyklu a zároveň obsahuje „id“ zápasu. Pole: $rozhod[] obsahuje „id“ všech rozhodčích. Proměnná $id_roz obsahuje „id“ rozhodčího v daném zápase. Proměnná: $index obsahuje zbytek po dělení proměnné: $i vydělené proměnnou: $poc_roz. Tedy index pole, ve kterém jsou uloženy „id“ rozhodčích, je každým průchodem cyklu zvýšen. Pokud se dosáhne konce pole, je pole indexováno opět od začátku. Kromě „id“ zápasu a „id“ rozhodčího je řádek tabulky vyplněn hodnotami nula, které značí nezadané skóre a nenastavené příznaky (0 ~ false). Nyní přejděme ke generování rozpisu zápasů. Nejprve uvedeme nejzajímavější část skriptu, která bude blíže rozebrána. 35

$vysledek2 = mysql_query("select * from tym"); $k=1;

//pro indexovani pole od jedne

while ($data2 = mysql_fetch_array($vysledek2)) { $nazvy[$k]=$data2['nazev'];

// ulozi nazvy tymu do pole

$k++; } $id_zap=1;

// id zapasu

for($i=1;$i<=$poc_tym;$i++) { for($j=1;$j<=$poc_tym;$j++) { if($i<$j) { $nazev_D = $nazvy[$i];

// nazev domácího tymu

$nazev_H = $nazvy[$j];

// nazev hostujícího tymu

$query = @MySQL_Query("INSERT INTO rozpis VALUES ('$nazev_D', '$id_zap', '1')"); $query2 = @MySQL_Query("INSERT INTO rozpis VALUES ('$nazev_H', '$id_zap', '0')"); $id_zap++; $query3 = @MySQL_Query("INSERT INTO rozpis VALUES ('$nazev_D', '$id_zap', '0')"); $query4 = @MySQL_Query("INSERT INTO rozpis VALUES ('$nazev_H', '$id_zap', '1')"); $id_zap++; } } }

V ukázce kódu nejprve uložíme názvy týmů do pole: $nazvy[]. Dále vidíme dva vnořené cykly, jejichž počet průchodů odpovídá počtu týmů v lize. Pokud je splněna podmínka „if“ (řídící proměnná prvního cyklu je menší než řídící proměnná druhého cyklu), vložíme během jednoho průchodu cyklem do tabulky „rozpis“ čtyři řádky. Uvědomme si, že pro jeden řádek tabulky „zápas“ jsou potřeba dva řádky v tabulce „rozpis“ (v každém zápase figurují dva týmy). Dva týmy se mezi sebou utkají dvakrát (doma a venku). Pokud si připomeneme, že sloupce tabulky „rozpis“ obsahují: název týmu, id zápasu, doma (‘0’ ~ true, '1' ~ false), a známe základy programování v PHP, není již co dodat. Tento algoritmus je velice jednoduchý a srozumitelný oproti jeho předchůdci, nad kterým jsem si dlouho lámal hlavu.

36

6.2.3 Běžný správce Běžný správce může provádět registrace: hřiště, týmu, hráče, správce a rozhodčího (viz hlavní správce). Může dále vkládat aktuality, změnit si své přihlašovací údaje a má přístup k interním kontaktům jako každý autorizovaný uživatel.

6.2.4 Rozhodčí Hlavní funkcí rozhodčího v této aplikaci je vkládání výsledků ze zápasů, které „pískal“. Rozhodčí tedy vybere z hlavní nabídky „Vložení výsledků“. Poté se mu zobrazí seznam se všemi zápasy, které pískal. Řádky seznamu může filtrovat například vybráním domácího týmu (viz obr. 13). Rozhodčí tedy může vložit výsledky (jen jednou), případně je upravit (úprava je možná, jen pokud žádný z kapitánů výsledky nepotvrdil).

Obrázek 13: Ukázka vkládání a úpravy skóre rozhodčím

Při kliknutí na „Upravit“ nebo „Vložit“ (viz obr. 13) se objeví příslušný formulář s vyplněnými názvy týmů. Jelikož se „id“ zápasu, s kterým bude pracováno, předává do dalšího formuláře metodou GET, musíme kontrolovat, zda rozhodčí nepodstrčil „id“ zápasu, který nepískal (../index.php?page_ide=r_zadej_v&oc=5). Kontrola je snadná: $query = mysql_query("select * from zapas where id = '$id_zap' and id_rozh <> '$id_roz'"); if (mysql_num_rows($query)>0) { echo"Nemáte oprávnění!"; $zobraz = 0; }

37

Pokud rozhodčí opravdu píská daný zápas a vyplněný formulář prošel kontrolou (pomocí regulárních výrazů), odpovídající řádek v tabulce „zápas“ se aktualizuje zadaným skóre. 6.2.5 Kapitán Hlavní funkcí kapitána je potvrzení výsledků ze zápasu, které vložil rozhodčí. Kapitán vybere z hlavní nabídky „Potvrzení výsledků“. Poté se mu zobrazí seznam zápasů, ve kterých tým hrál, a zároveň ještě nebyly potvrzeny. Řádky seznamu lze filtrovat (tým hrál doma nebo venku). Také kontrolujeme, zda rozhodčí nepodstrčil údaje, podobně jako u rozhodčího. Pokud je vše v pořádku, aktualizujeme tabulku „zápas“. Přesněji příznak „kap_d“ nebo „kap_h“ (záleží, zda kapitán zastupuje domácí nebo hosty). Dále se v tomto skriptu kontroluje, zda „zápas“ nepotvrdili již oba kapitáni. Pokud ano, zadané výsledky jsou již ověřeny a musí se započítat (do tabulky „tým“). Jeden tým již znám (kapitánův tým), druhý tým zjistím dle „id“ zápasu. $hraD = $data_1['hra_D'];

//počet vyhraných her – domácí

$hraH = $data_1['hra_H']; $legD = $data_1['leg_D']; $legH = $data_1['leg_H']; if($hraD > $hraH) {

//počet vyhraných legů – hosté

// vyhráli domaci (vyhráli více her, než hosté)

$query_upD = @MySQL_Query("UPDATE tym SET body = body + 3, …“); $query_upH = @MySQL_Query("UPDATE tym SET prohry = prohry +1, …"); } elseif($hraD = $hraH) {

//remiza

$query_upD = @MySQL_Query("UPDATE tym SET body = body + 1, …"); $query_upH = @MySQL_Query("UPDATE tym SET body = body + 1, …"); } else{

//vyhráli hosté

$query_upD = @MySQL_Query("UPDATE tym SET prohry = prohry +1, …"); $query_upD = @MySQL_Query("UPDATE tym SET body = body + 3, …"); } $que = @MySQL_Query("UPDATE zapas SET zapocteno=1 WHERE id=$id_zap"); MySQL_Close();

38

Ze skriptu je zřejmé, že do čtyř proměnných načteme skóre ze zápasu. Podle počtu vyhraných her (z jednoho utkání) zjistíme, který tým vyhrál (pokud nebyla remíza). Následně aktualizujeme tabulku „tým“ (dva řádky = dva týmy). Nakonec nastavíme v tabulce „zápas“ v odpovídajícím řádku příznak započteno.

6.2.6 Vkládání aktualit Vkládat aktuality mohou všechny autorizované osoby. Aktuality jsou přístupné i v neautorizovaném rozhraní.

Obrázek 14: Formulář pro vložení aktualit a následná ukázka vložené aktuality

Pro vkládání aktualit byl napsán jednoduchý editor (viz obr. 14). Umožňuje vkládat nadpis, klasický i formátovaný text, odkazy nebo „smajlíky“. Po kliknutí na tlačítko se do „textarey“ pomocí JavaScriptu vloží příslušný symbol. Aktuality se ukládají do databáze. Při jejich zobrazování se musí vložené symboly nahradit příslušnými tagy. To zajistíme pomocí PHP. Využijeme funkcí: str_replace, preg_replace.

39

6.2.7 Veřejně přístupné rozhraní Neautorizovaní uživatelé mohou v hlavním menu vybrat tyto položky: úvod, výsledky, aktuality, týmy, hřiště, fotogalerie, dokumenty, kontakty. 6.2.7.1 Výsledky Tato část obsahuje tabulku s průběžným pořadím týmů. Dále je zde možnost zobrazit výsledky konkrétního týmu v jednotlivých zápasech. 6.2.7.2 Aktuality Zde jsou zobrazeny aktuality vložené autorizovanými uživateli. Zobrazuje se posledních šest aktualit. 6.2.7.3 Týmy Zde je seznam týmů. Po vybrání konkrétního týmu vidíme informace o týmu a o jeho hráčích. 6.2.7.4 Hřiště V této části nalezneme informace o všech registrovaných hřištích (adresa, popis). Dále je zde uveden seznam, ve kterém jsou uvedeny týmy a jejich hřiště. 6.2.7.5 Fotogalerie V této části vidíme odkazy na jednotlivé galerie. K vytvoření galerie je použit program Zoner Photo Studio (více na http://www.zoner.cz). Galerie využívá technologií: htm, xml, JavaScript, Adobe Flash. 6.2.7.6 Dokumenty Zde jsou k dispozici dokumenty ve formátu: pdf.

6.3 Tvorba layoutu Vizuální rozložení dokumentu (webové stránky) bývá označováno jako layout. Než jsem začal výsledný layout (viz obr. 15) vytvářet, udělal jsem si několik návrhů na papír. Nakonec jsem se rozhodl, že vytvořím dva sloupce vedle sebe. Levý sloupec pro navigaci a pravý pro zobrazování obsahu. 40

Pro tvorbu layotu webových stránek jsou různé prostředky: 

rámy (zastaralé a mnoho nevýhod),



tabulky (zastaralé, vzhled přímo v HTML kódu),



kaskádové styly.

Zvolil jsem kaskádové styly. Vizuální bloky jsem vytvořil pomocí prvků: