Univerzita Karlova v Praze

Pedagogická fakulta

Katedra informa čních technologií a technické výchovy

BAKALÁ ŘSKÁ PRÁCE

Vývoj databázového rozhraní pro po číta čový slovník

Development of database application for computer glossary

Michal Dudek

Vedoucí práce: PhDr. Josef Procházka, PhD.

Studijní program: B7507 Specializace v pedagogice

Studijní obor: Informa ční technologie se zam ěř ením na vzd ělávání

2016

Prohlašuji, že jsem bakalá řskou práci na téma Vývoj databázového rozhraní pro po číta čový slovník vypracoval pod vedením vedoucího práce samostatn ě za použití uvedených pramen ů a literatury. Dále prohlašuji, že tato práce nebyla využita k získání jiného nebo stejného titulu.

V Praze 2016

......

Michal Dudek

Pod ěkování

Tímto bych rád pod ěkoval PhDr. Josefovi Procházkovi, PhD za odborné a vst řícné vedení, připomínky a cenné rady p ři zpracování tématu bakalá řské práce.

Dále bych rád pod ěkoval své rodin ě a p řítelkyni za trp ělivost a významnou podporu p ři studiu a řešení této práce.

ANOTACE

Obsahem práce je analyzovat a zhodnotit slovníky a slovníkové aplikace z oblasti terminologie informa čních technologií. Dle rozboru nej čast ějších problém ů, které se u po číta čových slovník ů nebo slovníkových aplikací vyskytují, je navrženo vlastní řešení databázového rozhraní pro po číta čový slovník. Práce předkládá modelový postup vývoje databázového rozhraní od analýzy až po ov ěř ení vlastní implementace části aplikace s ohledem na využití moderních technologií a metod k vývoji, které jsou v práci popsány. V záv ěru práce je část implementovaného rozhraní slovníku ov ěř ena pomocí jednotkových a funk čních test ů.

KLÍ ČOVÁ SLOVA

Slovníková aplikace, databázová aplikace, vývoj aplikace, agilní metodika, framework, vývojové prost ředí, jednotkové testy, funk ční testy.

ANNOTATION

The aim of the thesis is to analyze and evaluate dictionaries and dictionary applications focusing on terminology concernign information and communication technology. Based on the analysis of issues concerning such applications that are currently available, a database dictionary application is developed. The thesis presents the procedure of development all the way from analysis to the final implementation of the application core using current technologies and development paradigms. Final part of the thesis deals with unit and factory acceptance testing of the application.

KEYWORDS

Glossary application, database application, application development, agile methodologies, framework, development environment, unit test, factory acceptance test.

Obsah

Úvod ...... 7

Cíl práce ...... 7

1 Analýza existujících řešení po číta čových slovník ů ...... 8

1.1 Vymezení sledovaných parametr ů ...... 8

1.2 Pr ůběh analýzy ...... 9

1.2.1 Tišt ěné slovníky ...... 9

1.2.2 Elektronické slovníky ...... 10

1.3 Záv ěr analýzy ...... 11

2 Definice vlastního řešení slovníkové aplikace ...... 13

2.1.1 Dostupnost slovníku ...... 13

2.1.2 Uživatelské funkce ...... 13

2.1.3 Metody pln ění obsahu ...... 15

2.1.4 Grafické funkce ...... 16

3 Návrh slovníkové aplikace ...... 17

3.1 Design aplikace a výb ěr technologií ...... 17

3.1.1 Databázový systém ...... 18

3.1.2 Aplika ční rozhraní ...... 20

3.2 Role a procesy ...... 23

3.2.1 Role ...... 23

3.2.2 Procesy ...... 24

3.3 Konceptuální a logický model databáze ...... 27

4 Vývojové prost ředí ...... 30

5 Metody vývoje ...... 32

5.1 Rigorózní metody vývoje ...... 32

5.2 Agilní metody vývoje ...... 33

5.2.1 Extrémní programování ...... 34

5.2.2 Scrum ...... 34

6 Implementace databázového rozhraní ...... 36

6.1 Příprava prost ředí k implementaci ...... 36

6.2 Propojení prost ředí s nástroji pro vývoj ...... 36

6.3 Implementace databáze ...... 37

6.4 Problémy spojené s implementací ...... 37

7 Testování vlastní aplikace ...... 39

7.1 Jednotkové testy ...... 41

7.2 Funk ční testy ...... 43

7.3 Penetra ční testy ...... 45

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

8.1 Zhodnocení dosažení cíl ů ...... 47

8.2 Výstupy práce ...... 47

8.3 Záv ěre čné shrnutí práce ...... 48

9 Seznam použitých informa čních zdroj ů ...... 49

10 Seznam p říloh ...... 52

11 Přílohy ...... 53

Úvod V této práci se zabývám analýzou, návrhem a vlastní implementací části webového rozhraní pro po číta čový slovník. V analýze sleduji parametry, kterými jsou dostupnost slovníku pro uživatele, orientace ve slovníku a zp ůsob vyhledávání, možnost úprav nalezených výraz ů, interakce slovníku s uživatelem aj. Po uvedené analýze následuje definování vlastních funkcí a návrh databázového rozhraní pro po číta čový slovník. V záv ěru práce otestuji vlastní část rozhraní pomocí jednotkových a funk čních test ů.

Jako sou část práce popisuji postup vývoje databázového rozhraní pro po číta čový slovník, výb ěr nástroj ů a metod pro samotný vývoj a ukázky řešení problém ů, které se p ři vývoji objevily. Tento popis slouží jako modelový příklad realizace databázové aplikace a případnému čtená ři nabídne souhrn nástroj ů, metod a postup ů, kterými se m ůže řídit p ři realizaci vlastní databázové aplikace. Během realizace databázového rozhraní analyzuji dostupnost technologií a nástroj ů, které lze pro vývoj rozhraní využít. Při porovnávání technologií a nástroj ů zohled ňuji sou časné trendy a možnosti t ěchto technologií a nástroj ů.

Cíl práce Cílem práce je vytvo ření modelového postupu návrhu databázové aplikace včetn ě dodržení agilních metodik vývoje. Sou částí práce je rovn ěž nezbytná analýza aktuáln ě dostupných řešení, nasazení vhodné techniky vývoje, realizace a ov ěř ení modelového řešení.

7

1 Analýza existujících řešení po číta čových slovník ů Obsahem analýzy je získat p řehled dostupných řešení po číta čových slovník ů, porovnat jejich klady a zápory z pohledu dostupnosti slovníků, obsažených pojm ů a jejich výkladu, poskytovaných uživatelských funkcí a metod zadávání obsahu. Tyto parametry jsou st ěžejní charakteristikou pro slovníky nebo slovníkové aplikace. Analýzou, ve které sleduji zmín ěné parametry, zjistím, zda jsou na českém trhu dostupné po číta čové slovníky nebo slovníkové aplikace, které vyhovují sledovaným parametr ům. V případ ě, že takový slovník neexistuje, vytvo řím vlastní návrh s řešením nalezených nedostatk ů vyplývajících z analýzy.

1.1 Vymezení sledovaných parametr ů

Dostupnost slovníku Dostupností slovníku sleduji, zda je možné slovník využít zdarma, nebo za úplatu, je-li slovník p řístupný online, jako aplikace spustitelná na PC, či v tišt ěné podob ě, a zda je tišt ěná podoba k dostání v prodeji.

Obsah odborných pojm ů a jejich výkladu Obsah odborných pojm ů a jejich výkladu je klí čový pro zařazení slovníku do analýzy. Po číta čové slovníky, které obsahují mén ě než 100 odborných pojm ů a u nichž je výklad většiny pojm ů kratší než p ět slov, do své analýzy nezahrnuji. U po číta čových slovník ů za řazených do analýzy sleduji četnost výskytu doprovodného materiálu v podob ě audio- vizuálního obsahu.

Uživatelské funkce Uživatelskými funkcemi sleduji možnost registrace, p řihlášení, hodnocení výkladu pojm ů, možnost upozornit na nedostatky ve výkladu, zp ůsob vyhledávání a řazení nalezených výsledk ů.

Metody zadávání obsahu U online po číta čových slovník ů zjiš ťuji, zda mají uživatelé možnost zadávat obsah do slovníku, případn ě jakými metodami, a jsou-li uživatelé za p řisp ění ohodnoceni.

8

1.2 Pr ůběh analýzy Na českém trhu jsem nalezl po číta čové slovníky v podob ě tišt ěných slovník ů nebo online webových stránek. Po číta čový slovník v podob ě aplikace spustitelné na po číta či jsem nenalezl. Tišt ěné a elektronické slovníky ve své analýze odd ěluji do vlastních kapitol, a to z důvodu rozdílného zacházení se slovníkem, vycházejícím z principu t ěchto slovník ů.

1.2.1 Tišt ěné slovníky K analýze tišt ěných po číta čových slovník ů jsem si po řídil fyzický slovník a na základ ě jeho prohlédnutí jsem si zapsal výsledky pozorování. Na českém trhu jsem objevil celkem čty ři solidní po číta čové slovníky: Velký po číta čový lexikon (Winkler, 2009), Slovník po číta čových pojm ů a zkratek (Vorá ček, 1998), Slovník po číta čové informatiky (Říha, 2002) a Velký po číta čový slovník (Nádb ěla, 2006). Tyto slovníky obsahují alespo ň základní výklad pojm ů a nejsou zam ěř eny na překlad do českého jazyka. Po číta čové slovníky, které se zam ěř ují pouze na p řeklad, jsem opomenul. Získání fyzických slovník ů nebylo v ůbec jednoduché vzhledem k jejich poslednímu roku vydání. Nejmladší tišt ěný slovník byl vydán v roce 2009.

Tišt ěné slovníky jsou z pohledu vývoje informa čních technologií zastaralé, přesto z analýzy vycházejí jako jedny z nejlepších zdroj ů informací. Obsah t ěchto slovník ů je bohatý, n ěkdy zahrnují až tisíce odborných pojm ů s výkladem, a pocházejí od odborník ů z praxe (Winkler, 2009), (Nádb ěla, 2006), což zaru čuje výklad ům pojm ů důvěryhodnost, na rozdíl od zdroj ů elektronických, které jsou často spravovány neznámým autorem. Tišt ěné slovníky procházejí před vydáním pe člivou korekturou, a proto jsou vhodné jako ov ěř ený pramen informací a následné citace.

Nedostatky tišt ěných slovník ů Mezi zásadní nedostatky tišt ěných slovník ů řadím zp ůsob vyhledávání. Čtená ř nemá možnost využít fulltextové vyhledávání, řazení obsahu s využitím filtr ů, ozna čení požadovaného obsahu, nap ř. barevným štítkem, a obsah podle tohoto štítku seskupovat, přehrávání audio-vizuálních informací, atd. Sou časné tišt ěné po číta čové slovníky nenabízí žádnou formu interaktivní spolupráce se čtená řem a práce se slovníky je časov ě náro čnější než u elektronických variant.

Další nevýhodou tišt ěných slovník ů je po řizovací cena, která se b ěžn ě na českém trhu pohybuje mezi 150K č až 700K č, záleží na konkrétním slovníku a dostupnosti v prodeji.

9

U tišt ěných slovník ů postrádám i pohotové vyhledání pojmu, protože s tišt ěnými slovníky se kv ůli jejich váze hůř e manipuluje, a tudíž nemohu mít slovník vždy u sebe.

Ze své podstaty mají tišt ěné slovníky nevýhody p ředevším:

a) Ve složitém a zdlouhavém vyhledávání informací, bez možnosti filtrování obsahu. b) V pasivním p řístupu ke čtená ři, tj. čtená ř nemá možnost interaktivn ě vst řebat výklad pojmu. c) V aktualizaci informací. Pro opravu nebo aktualizaci informací je nutné nechat vytisknout slovník nový. d) V časovém rozkladu a nenávratném poškození tišt ěného slovníku. e) V pohotovém využití slovníku, který není vždy dostupný kv ůli obtížné manipulaci.

1.2.2 Elektronické slovníky Na rozdíl od tišt ěných slovník ů je elektronických po číta čových slovník ů nep řeberné množství. P ři hledání na internetu jsem narazil na desítky slovník ů, ale jen málo z nich působilo uceleným dojmem. Mnohé z el. slovník ů jsou slovníky firemní, dopl ňující odborný text, který má firma umíst ěný na svých webových stránkách. Jiné slovníky jsou plné slang ů a akronym ů. Takové slovníky slouží spíše pro hrá čské komunity než ke sledovanému ú čelu této práce.

Oproti tišt ěným slovník ům mohou elektronické slovníky nahradit výše zmín ěné nevýhody, jimiž jsou interaktivní práce se čtená řem, filtrování obsahu podle vlastních kritérií a audio- vizuální doprovod obsahu.

Hlavní výhodu el. slovník ů shledávám ve snazším a rychlejším vyhledávání oproti slovník ům tišt ěným. V el. slovníku mohu jednoduše aktualizovat nebo upravovat již zve řejn ěné informace a přidávat odborné pojmy bez nutnosti dalšího vydání nového slovníku. El. slovník mohu zálohovat, a p ředejít tak trvalému poškození. El. po číta čové slovníky z mé analýzy jsou dostupné online a zdarma, což z nich činí lehce dostupný zdroj informací.

Nedostatky el. slovník ů Mezi výrazné nedostatky el. po číta čových slovník ů řadím validitu informací a gramatickou nekorektnost. Autoři slovník ů jsou v ětšinou anonymní, a proto nelze ur čit, zda jsou to odborníci, kte ří znají správný význam odborných pojm ů, a zda neudávají špatný nebo

10 zkreslující význam pojmu. Ve své analýze jsem narazil pouze na jediný el. po číta čový slovník, u kterého byl uveden přímo 1 jeho autor.

Souhrnn ě mezi nedostatky el. slovník ů pat ří:

a) validita informací b) gramatická a stylistická nekorektnost obsahu c) nežádaný obsah, který p ředstavují reklamy d) závislost na internetovém p řipojení

1.3 Záv ěr analýzy Nejnad ějn ějším zástupcem el. slovník ů je IT-Slovník.cz 2. Slovník je dostupný online, zdarma a nabízí uživatelské funkce, jako je vyhledávání a možnost vkládání návrhu dalších nenalezených pojm ů ve slovníku, a to zadáním názvu pojmu a krátkého popisu do formulá ře. Obsah tohoto slovníku se blíží k po čtu 2700 slov, což představuje vzhledem k analýze jednu z nejobsáhlejších databází informací v kategorii el. slovník ů, viz tabulka č. 1 na následující stránce. Navíc je tento slovník stále aktivní a nové pojmy s každým týdnem p řibývají.

Slovník částe čně spl ňuje sledované parametry analýzy, při procházení slovníku jsem však bohužel neobjevil žádný audio-vizuální materiál, který by doplnil výklad pojmu, ani žádnou formu interaktivního obsahu. Zárove ň jsem ve slovníku nenalezl možnost seskupování pojm ů dle vlastního ozna čení, nebo hodnocení pojmu. Slovník nabízí pouhé čtení výkladu, které je v některých p řípadech velmi stru čné a laikovi pojem dostate čně nevysv ětlí 3.

Ve své analýze jsem mezi el. po číta čovými slovníky nenalezl zástupce, který by spl ňoval sledované parametry. Auto ři el. verzí po číta čových slovník ů nevyužívají možného potenciálu, aby čtená ři nabídli interaktivní výklad odborných pojm ů, nebo výklad doplnili o audio-vizuální obsah. V některých p řípadech nabízí auto ři el. po číta čových slovník ů hodnocení výkladu komentá řem. Tento zp ůsob hodnocení se příliš nevyužívá, to potvrzují i sou časné trendy na sociálních sítích, kde se používá buď hodnocení vyjád řené v podob ě ikon palc ů, srdí ček, hv ězdi ček aj., nebo hodnocení vyjád řené graficky či číseln ě, p řípadn ě procentuáln ě. Žádný ze slovník ů z analýzy nenabízí čtená ři možnost nahlásit p řípadný

1 Slovník po číta čové informatiky a sítí, dostupný na adrese: http://www.svetsiti.cz/slovnik.asp. 2 IT-Slovník.cz, dostupný na adrese: http://it-slovnik.cz. 3 Pojem „prohlíže č“, dostupný na adrese: http://it-slovnik.cz/pojem/prohlizec 11 nedostatek ve výkladu pojm ů, čímž se autor ochuzuje o zp ětnou vazbu a p řípadné nedostatky musí vyhledat sám.

Uživatelské funkce Název slovníku Dostupnost Počet výrazů Vyhledávání a interaktivita Online, zdarma, Slovník počítačové veřejný bez 5300 Přesný výskyt Čtení, komentáře informatiky a sítí 4 registrace

Online, zdarma, Čtení, komentáře, Přesný výskyt, IT-Slovnik.cz veřejný bez 2700 přidávání dalších fulltextové registrace návrhů

Online, zdarma, Svět Hardware - Slovník veřejný bez 1100 Fulltextové Čtení základních pojmů registrace Online, zdarma, ABCLinuxu.cz - Výkladový veřejný bez 590 Fulltextové Čtení slovník registrace Online Online, zdarma, PlayGate.cz - Slovník veřejný bez 350 Fulltextové Čtení počítačových pojmů registrace Online, zdarma, Bezpečný internet.cz - veřejný bez 150 Fulltextové Čtení Slovník registrace Online, zdarma, PC-IN Plzeň - Slovník ICT veřejný bez 130 Přesný výskyt Čtení pojmů registrace Online, zdarma, WebSnadno - Slovník veřejný bez 114 Žádné Čtení počítačových pojmů registrace Velký počítačový lexikon V prodeji 5000 Abecedně Čtení Velký počítačový slovník V prodeji 3500 Abecedně Čtení Slovník počítačové Omezený prodej 3000 Abecedně Čtení

Tištěné informatiky Slovník počítačových Omezený prodej 1700 Abecedně Čtení pojmů a zkratek Tabulka č. 1 – Souhrn analýzy po číta čových slovník ů, platné k únoru 2016. Zdroj: Autor

4 Autor tohoto slovníku uvádí, že základ slovníku je p řevzat z tišt ěného slovníku Slovník po číta čové informatiky: Výkladový slovník pro práci s informacemi (Říha, 2002). 12

2 Definice vlastního řešení slovníkové aplikace Vycházím z nedostatk ů, které uvádím v záv ěru analýzy pro definici vlastních funkcí a návrh slovníkové aplikace dle sledovaných parametr ů. Vý čet parametr ů zárove ň využívám jako rozd ělení do jednotlivých kapitol, které samostatn ě popíšu. V každé z těchto kapitol uvádím možnosti uživatelských funkcí vlastní slovníkové aplikace.

2.1.1 Dostupnost slovníku Z analýzy v tabulce č. 1 vyplývá, že všechny online po číta čové slovníky jsou dostupné zdarma a bez nutné registrace uživatele. Vlastní slovníková aplikace bude rovn ěž ve řejn ě přístupná zdarma, až na výjimku registrace uživatele. Ta je podmín ěna využitím některých uživatelských funkcí, p ři kterých je t řeba evidovat uživatelem nastavené hodnoty, nap ř. štítky u vybraných pojmů a vyhledávání pomocí t ěchto štítk ů. Registrace bude rovn ěž voln ě p řístupná.

Textový obsah slovníku bude ší řen pod licencí Creative Commons BY-SA , která umož ňuje uživatel ům libovoln ě nakládat s výkladem u pojm ů při uvedení p ůvodního zdroje a následném zachování stejné licence. Uživatelé tak mohou obsah slovníku libovoln ě ší řit, upravovat, sdílet aj. „Licence Creative Commons jsou souborem ve řejných licencí, které přinášejí nové možnosti v oblasti publikování autorských d ěl“. „Nejsou pop řením klasického pojetí autorského práva, jsou jeho nadstavbou a jako takové vycházejí z ob čanského zákoníku (§ 2358 – 2389 Zákona č. 89/2012 Sb., ob čanský zákoník)“. „Obliba licencí Creative Commons vychází p ředevším z jejich mezinárodní srozumitelnosti“ (Creative Commons Česká Republika, 2016). V dolní části stránky s výkladem pojmu pak uživatelé naleznou vygenerovanou citaci, kterou mohou využít pro správné uvedení zdroje.

2.1.2 Uživatelské funkce

Základní uživatelské funkce Mezi základní uživatelské funkce řadím registraci a p řihlášení uživatele. Bez t ěchto funkcí nelze provozovat mnoho jiných uživatelských funkcí, jež popisuji v následujících odstavcích. Základní funkcí je i kontaktní formulá ř, p řes který m ůže jakýkoliv uživatel odeslat své sd ělení.

13

Vyhledávání Nejd ůležit ější uživatelskou funkcí ve slovnících je vyhledávání. Uživatel má možnost vyhledávat zadáním výrazu do textového pole a p ři potvrzení výrazu se tento výraz vyhodnotí. Jestliže existuje p řesná shoda zadaného výrazu v textovém poli s pojmem ve slovníku, je zobrazena stránka s informacemi o pojmu. V případ ě, že zadaný výraz má více než jednu p řesnou shodu 5, zobrazí se stránka se seznamem pojm ů shodného názvu a u každého pojmu krátký popis, podle kterého lze pojem identifikovat. Další možností je fulltextové vyhledávání, které prochází krátkými popisy a výklady pojm ů ve slovníku a hledá výskyt zadaného výrazu. P ři nalezení jednoho a více výskyt ů fulltextového vyhledávání je rovn ěž zobrazen seznam s pojmy a popisem, u nichž byl výraz v popisu nebo výkladu nalezen. Poslední možností je nenalezení žádné shody ani v jedné z předchozích možností, v tomto případ ě je uživatel vyzván, aby výraz přidal jako chyb ějící pojem do slovníku.

Uživatel m ůže vyhledávat pojmy i dle kategorií, do kterých je pojem za řazen, a to zadáním symbolu k řížku a názvu kategorie. Podobn ě m ůže uživatel vyhledávat i pomocí symbolu zaviná če a jména autora, nebo příkazu /tag a názvu vlastního štítku. Tyto výrazy nazýváme regulárními výrazy, zkrácen ě regexpy z angl. regular expression. Stejnou metodu využívá i nejznám ější vyhledáva č Google, u kterého místo zaškrtávacího polí čka pro vyhledávání na konkrétních webových stránkách sta čí zadat regulární výraz site:adresa stránek a klí čový výraz . Pro vyhledávání s využitím názvu štítk ů musí být uživatel přihlášen a mít nastavené štítky.

Štítky Štítky jsou další uživatelskou funkcí, která slouží k seskupování pojm ů do skupin, jež si uživatel sám nadefinuje podle pot řeby. Pojmy lze takto seskupovat nap říč více štítky najednou, tzn., že jeden pojem m ůže mít jeden uživatel ozna čen n ěkolika štítky zárove ň.

Přidávání pojm ů Přidávání pojm ů do slovníku je další významná uživatelská funkce, díky které se m ůže slovník rozši řovat o další pojmy. Přidávání pojm ů je umožn ěno náhodným i p řihlášeným uživatel ům. Pojmy zadané uživatelem nejsou ihned ve řejné a odeslaný návrh musí projít

5 Shodný výraz m ůže být nap říklad ZIP jako souborový formát a ZIP jako nosi č dat. 14

úpravami, aby byla zajišt ěna kvalita obsahu ve slovníku. Při p řidávání pojmu má uživatel možnost k pojmu přiřadit audio-vizuální obsah, a tím rozší řit výklad o prostý text.

Hodnocení pojm ů Mezi další chyb ějící funkce vyplývající z analýzy pat ří hodnocení pojmu. Hodnocení slouží jako zp ětná vazba od uživatel ů vyjad řující kvalitu pojmu. Vyjád ření hodnocení je procentuální a hodnotit m ůže pouze p řihlášený uživatel, aby nebylo hodnocení zneužito. Každý uživatel m ůže hodnotit pouze jednou. Jakmile vyjád ří své hodnocení, zobrazí se jeho hodnocení pod celkovým hodnocením všech uživatel ů a uživatel si m ůže porovnat své hodnocení s celkovým pr ůměrem. Jakmile je špatn ě hodnocený pojem upraven, veškeré hodnocení se automaticky vynuluje a uživatel m ůže op ět hodnotit.

Hlášení problému u pojm ů Hlášení problému je další zp ětnou vazbou, kterou mohou uživatelé využít. Hlášení slouží k vyjád ření závažn ějších problém ů, jakými jsou nap ř. porušení autorské licence, gramatické chyby ve výkladu, nefunk ční mediální obsah aj. Funkce je p řístupná pouze pro přihlášené uživatele, a to proto, aby nedošlo ke zneužití. P ři v ětším po čtu nahlášených chyb se zobrazí varování pro uživatele, které upozor ňuje na problémy.

2.1.3 Metody pln ění obsahu Obsah slovníku tvo ří návrhy uživatel ů. Přidané návrhy pojm ů nejsou automaticky ve řejné, aby byla zachována úrove ň výkladu, nebo aby nedošlo k porušení autorských práv t řetí strany. Neve řejné pojmy upravují edito ři, kte ří kontrolují validitu informací a gramatickou korektnost. V případ ě, že u pojmu chybí citace a dopl ňkový materiál v podob ě obrázk ů, videa, zvuk ů nebo jiných soubor ů, editor takový obsah doplní, je-li to možné.

Pln ění obsahu je minimáln ě t řífázový proces, který zajistí, aby byl obsah pojmu validní a správný. První fáze je p řísp ěvek od náhodného nebo registrovaného uživatele, který odešle sv ůj návrh. V tomto návrhu má uživatel možnost zadat název pojmu, kategorii, do které pojem spadá, krátký popis do 255 znak ů a odkázat na audio-vizuální materiál nebo jiné dopl ňkové soubory. Ve druhé fázi editor zkontroluje informace v návrhu odeslaném uživatelem. Shledá-li informace správnými a dosta čujícími, doplní editor pojem o jiné kategorie, než jsou kategorie zadané uživatelem v návrhu, a p ředá pojem k poslední fázi. Objeví-li nedostatky ve výkladu, zavád ějící informace nebo stru čný výklad, doplní a upraví obsah pojmu sám. V poslední fázi pak editor zkontroluje gramatickou korektnost

15 výkladu a p řeklepy, aby byl obsah pojmu na úrovni. Poté ozna čí pojem jako autorizovaný a pojem bude ve řejn ě p řístupný.

Celý proces je pro práci editora náro čný, nelze však jiným zp ůsobem zaru čit, že informace, které budou v obsahu výkladu pojmu, budou zárove ň validní a gramaticky korektní. Proces eliminuje p ředchozí nedostatky vycházející z analýzy u el. slovník ů, ve kterých se vyskytují chyby nebo zavád ějící výklady pojm ů.

2.1.4 Grafické funkce Grafické funkce jsou funkce pro zobrazení informací, které se nacházejí v databázi a nejsou sou částí uživatelského grafického rozhraní , zkrácen ě GUI z angl. Graphical User Interface. Pomocí t ěchto funkcí se zobrazují informace o pojmu, kategorie, do kterých pojem pat ří, hodnocení pojmu, autora pojmu, štítky, které má uživatel nastaven a varování pro uživatele.

Zobrazení kategorií slouží k orientaci uživatele, do jakého oboru pojem spadá, ale zárove ň může uživatel tyto kategorie procházet a hledat další pojmy z oblasti svého zájmu.

Hodnocení pojmu vyjad řuje spokojenost uživatel ů s popisem a výkladem pojmu. V případ ě nízkého hodnocení je uživatel vyzván ke spolupráci, aby výklad obohatil. Pojmy, které mají nízké hodnocení, lze v databázi filtrovat, a přestože není u pojmu evidován žádný problém, jsou tyto pojmy navrhovány editor ům k úprav ě.

Informace o autorovi využije uživatel nap ř. p ři budoucím vyhledávání nebo při cíleném sledování p řísp ěvk ů svého oblíbeného autora. Jméno autora je uživatelské jméno zadané při registraci.

Štítky jsou u p řihlášených uživatel ů zobrazeny v postranní části GUI a zárove ň u pojm ů, které jsou uživatelem ke štítku p řiřazeny. Štítky mohou nabývat r ůzných barev, ale název štítku je vždy bílý.

16

3 Návrh slovníkové aplikace V této kapitole se zabývám návrhem vlastního řešení databázového rozhraní, které se skládá z návrhu designu databázového rozhraní, analýzy a výb ěru vhodných technologií, zmapování rolí, proces ů a jejich definic a návrhu databázového modelu. Při návrhu vycházím z vlastních definic funkcí v kapitole č. 2.

3.1 Design aplikace a výb ěr technologií V kapitole design a výb ěr technologií se v ěnuji návrhu struktury databázového rozhraní a tomu, z jakých částí bude rozhraní sestaveno. Pro každou část rozhraní provádím povrchovou analýzu dostupných technologií a volím technologii a prost ředí, ve kterém bude část rozhraní vyvíjena.

Zadáním práce je vyvinout databázové rozhraní pro po číta čový slovník. Rozhraní vytvo řím jako webovou aplikaci, která přistupuje k informacím uloženým v databázi. Webovou aplikaci doplním o GUI pro snadn ější práci s formulá ři a dalšími prvky, které webovou část rozhraní ovládají. Databázové rozhraní má strukturu znázorn ěnou na obrázku č. 1. Každou z této části popisuji v samostatné kapitole.

Obrázek č. 1 – Blokové schéma databázového rozhraní slovníkové aplikace. Zdroj: Autor

17

3.1.1 Databázový systém Na obrázku č. 1 znázor ňuji propojení dat s aplika čním rozhraním. Data jsou zpracována skrze systém řízení báze dat , zkrácen ě S ŘBD, „ten spole čně s databází tvo ří databázový systém“, zkrácen ě DBS (Šeda, 2002, str. 4).

Databázové systémy mají mnoho podob. Nejrozší řen ějšími jsou rela ční SQL systémy, po kterých následují NoSQL systémy. NoSQL systémy se dále d ělí na dokumentové, Key- value, Search engine, Graph DBMS aj. Statistika a přehled 20 nejrozší řen ějších systém ů jsou uvedeny v příloze č. 1.

NoSQL systémy NoSQL , z angl. Not-Only SQL, databáze nemají žádnou jasně vymezenou podobu struktury dat, proto je lze b ěhem vývoje aplikace jakkoliv upravovat podle pot řeby a není nutné kv ůli tomu m ěnit celé schéma databáze, které p ředstavuje velké zásahy. Tyto databáze jsou dynamické, což je významná vlastnost p ři vývoji aplikace agilní metodou vývoje. Další klí čovou vlastností je ukládání do vlastních datových soubor ů, umož ňující nezávislost na jedné hlavní databázi. NoSQL databáze vykazují i rychlejší zpracování dat, protože nejsou závislé na referen ční integrit ě6 nebo uživatelském oprávn ění. Výkon NoSQL databází je výrazn ější než u databází typu SQL. Lepší výkon spo čívá v práci p římo s objekty, které jsou do datových soubor ů umíst ěny. Oproti na čítání jednotlivých záznam ů – řádk ů v rela čních databázích pracují aplikace přímo s informacemi objektu a jeho vlastnostmi, které mají podobu prom ěnných. Přímý přístup k objekt ům a jeho vlastnostem usnad ňuje vývoj aplikace, protože se programátor nemusí starat o datovou strukturu databázového systému, nýbrž pracuje s objektem p římo (Celko, 2014). K aktuáln ě nejrozší řen ějším NoSQL databázím řadíme MongoDB, Cassandra, Elasticsearch, HBase a Neo4j. Viz p říloha č. 1.

I p řes všechny uvedené výhody NoSQL databází volím relační SQL SŘBD. Rozhraní úmysln ě navrhuji pro využití rela ční SQL SŘBD, protože tento systém zajišťuje klí čové vlastnosti, jako jsou integrita a konzistence dat, jednozna čná struktura a další užite čné vlastnosti pomocí tzv. ACID transakcí – „je to akronym pro atomicitu – konzistenci – izolovanost – trvalost.“ „ Atomicitou myslíme, že se provede celá transakce nebo nic, transakce je ned ělitelná . Konzistence znamená, že jakákoliv transakce v konzistentním stavu se m ůže p řenést do jiného konzistentního stavu, tedy není nijak porušena integrita

6 Nezkoumají se vztahy mezi entitami a platnost cizích klí čů . 18 dat. Izolovaností myslíme odd ělení transakcí od sebe, dokud není celá transakce provedena. A trvalost se projevuje tím, že jednou provedená transakce v databázi z ůstane, a to i v případ ě, pokud následn ě selže systém. “ (Date, 2011, str. 180). Tyto transakce už nemusím ošet řit sám ve vlastním kódu aplikace.

Vylou čením rela čních SQL databází bych p řišel o zmín ěné výhody v podob ě ACID transakcí, které jsou vyvíjeny profesionálními vývojá ři. Snaha docílit stejné rychlosti a co nejlepší bezchybnosti při implementaci vlastního kódu by vývoj aplikace zbyte čně protáhla a výsledek vlastního ošet ření aplikace by byl nejasný.

Rela ční SQL systémy Mezi nejznám ější rela ční databázové systémy pat ří Oracle, PostgreSQL, MS SQL, SAP, MySQL, SQLite nebo nov ější MariaDB. Některými z t ěchto rela čních systém ů jsou draze placené systémy pro podnikové řešení, u kterých se p ředpokládá práce se statisíci až milióny záznam ů v co nejkratším časovém úseku. I když mají velmi dobré výkonnostní vlastnosti, jsou pro m ůj ú čel tyto databázové systémy drahé a implementace těchto systém ů by byla zbyte čně náro čná.

Proto vybírám Open Source rela ční SQL systémy, jako jsou MySQL, PostgreSQL, SQLite a MariaDB, jež jsou k využití zdarma a posta čí nárok ům mé aplikace. Z těchto Open Source systém ů je t ěžké najít jednozna čného kandidáta, který svými výhodami převyšuje ostatní.

V bakalá řské práci Výkonnostní srovnání rela čních databází Lukáše Košárka nacházím PostgreSQL nejlepšího kandidáta z Open Source systém ů. „ Ten dosáhl vůbec nejlepšího výsledku s jedním p řipojeným vláknem“ (Košárek, 2010, str. 36), ale zárove ň se projevily potíže p ři vícenásobném p řipojení uživatel ů. „PostgreSQL, stejn ě jako Firebird, spouští pro každé p řipojení nový proces. P ři pokusu o spušt ění takto velkého po čtu proces ů nebylo možné alokovat dostatek opera ční paměti pro každé p řipojení a PostgreSQL se ukon čil. K ukon čení docházelo v okamžiku 100% napln ění opera ční pam ěti.“ (Košárek, 2010, str. 31). Vyšší propustnost v počtu připojených vláken k DBS u Open Source systém ů daleko lépe zvládá MySQL, jak je patrné z grafu v příloze č. 2.

Bohužel jsem nenašel odborné publikace, které by se zabývaly srovnáním rela čních SQL systém ů v sou časnosti a zahrnovaly by i novou odnož MariaDB. Na odborných webových stránkách v ěnované MariaDB jsem nalezl výsledky test ů p ři porovnání MySQL a

19

MariaDB. Z výsledk ů v článku Performance evaluation of MariaDB 10.1 and MySQL 5.7.4-labs-tplc (Lindstrom, 2014) a článku MariaDB 10.1 and MySQL 5.7 performance on commodity hardware (Schwenke, 2015) je patrné, že MariaDB má při testování nejaktuáln ějších verzí t ěchto systém ů lepší výkon než MySQL.

MariaDB je odnož systému MySQL, který aktuáln ě pat ří spole čnosti Oracle. Na rozdíl od MySQL je MariaDB aktivn ě vyvíjena a pravideln ě aktualizována, systém nabízí použití nových engine, jako je Percona XtraDB Storage Engine , které nahrazuje InnoDB , a posouvá se za hranice limit ů toho engine, jenž spo čívá v efektivn ějším využití pam ěti (Percona LLC, 2016), stejn ě jako Aria Storage Engine , kterou nahrazuje MyISAM (MariaDB Corporation, 2010).

Jako databázový systém pro po číta čový slovník jsem si zvolil MariaDB, který z analýzy vychází jako nejrychlejší systém a nabízí nové zp ůsoby ukládání dat do databáze.

3.1.2 Aplika ční rozhraní Další částí databázového rozhraní slovníku je aplika ční rozhraní, které komunikuje mezi DBS a předává zpracované informace uživateli. Aplika ční rozhraní tvo ří kombinace webových technologií. V této kapitole se zabývám volbou a popisem webových technologií použitých pro realizaci rozhraní slovníku.

Statické, interaktivní a dynamické stránky Statické stránky jsou tvo řeny v jazyce HTML , z angl. Hyper Text Markup Language, kterým vytvá říme objekty v blocích pomocí zna ček. Bloky mají u každého webového prohlíže če jinou grafickou podobu. Pro sjednocení stylu a vytváření grafických efekt ů jsem využil kaskádové styly, zkrácen ě CSS z angl. Cascade Style Sheet.

Pro vytvo ření dynamických a interaktivních stránek využívám knihovnu jQuery, která je psaná v jazyce JavaScript , zkrácen ě JS. JavaScriptové knihovny, jako nap říklad již zmín ěná jQuery nebo React.js, uleh čují práci p ři tvorb ě dynamických prvk ů ve stránce.

Podstata t ěchto knihoven spo čívá v již p ředepsaných blocích kódu JavaScriptu, které nazýváme metodami. Místo dlouhého psaní vlastního kódu JS využívám již napsané metody , které mi umož ňují efektivn ěji pracovat s HTML dokumentem v podob ě objekt ů. Objekty se hierarchicky seskupují do stromové struktury HTML dokumentu. Každý prvek má v dokumentu svou p řesnou hierarchickou pozici, n ějakého p ředka, p řípadn ě potomka, nap ř. formulá ř je potomkem dokumentu a zárove ň rodi čem textového pole . Této logice

20

říkáme Document Object Model , zkrácen ě DOM (Rutter, 2011). Pro vytvo ření dynamiky zavolám požadovanou metodu a metod ě předám název objektu, se kterým má pracovat. Viz ukázka kódu:

// Předání hodnoty z posuvníku do textového pole

$(document).ready(function(){

function displayValSlide(){

var sliderValue = $("#scoreslider").val();

$("#scoretext").val(sliderValue + ' %');

}

$("#scoreslider").change(displayValSlide);

displayValSlide();

});

V ukázce kódu nejprve definuji funkci $(document).ready() , aby se všechny JavaScriptové metody vykonaly, až po na čtení celého HTML dokumentu. Následuje definice metody displayValSlide() , která na čítá hodnotu z objektu s identifikátorem scoreslider a na čtenou hodnotu p ředá do objektu s identifikátorem scoretext . Poté přichází na řadu metoda, která vyvolá p ředchozí metodu displayValSlide() při jakékoliv zm ěně v objektu scoreslider . Jakmile uživatel zm ění hodnotu na posuvníku, hodnota se automaticky zobrazí v textovém poli.

Knihovna jQuery obsahuje metody pro:

a) manipulaci s objekty b) CSS manipulaci c) HTML události d) efekty a animace e) AJAX, angl. Asynchronous JavaScript and XML

Na internetu existují stovky až tisíce již hotových projekt ů, které si stačí pouze stáhnout a přizp ůsobit si je k vlastnímu ú čelu, nebo grafickým vzhledem. Zajímavou a obsáhlou databází takových projekt ů je The jQuery Plugin Registry , dostupná na adrese: http://plugins.jquery.com. Databáze disponuje až stovkami hotových projekt ů s různým zam ěř ením na práci s grafickým rozhraním, vytvá ření fotoalb, interaktivní formulá ře aj.

21

Skriptování na stran ě serveru HTML, CSS a JavaScript jsou webové technologie, které pracují na stran ě uživatele. I když s kombinací těchto technologií dosáhnu graficky zpracovaných a dynamických stránek, stále postrádám technologii, díky které mohu vykonávat úkony na stran ě serveru, nap ř. komunikovat s SQL S ŘBD nebo generovat HTML dokumenty podle pot řeby.

Mezi nejrozší řen ější jazyky na stran ě serveru pro webové aplikace pat ří PHP, .NET a Java. Ze statistiky Usage of server-side programming languages for websites 7 uvedené na nezávislém webu, který poskytuje informace o využívaných technologiích, je z řejmé, že nejpoužívan ější jazyk pro webové aplikace je PHP (W3Techs, 2016).

Jazyk PHP má solidní dokumentaci, disponuje obrovským množstvím funkcí, je nezávislý na platform ě, podporuje velké množství databázových systém ů a je standardem pro webhostingové služby. To jsou d ůvody, pro č jsem se rozhodl využít tento jazyk pro vývoj databázového rozhraní.

Frameworky V jazyce PHP existuje celá řada populárních framework ů. „Frameworky mají klí čový význam pro vývoj rozsáhlejších objektov ě orientovaných softwar ů. Slibují vyšší produktivitu a kratší vývojový čas a zárove ň znovupoužití designu a kódu.“ (Riehle, 2000, str. 1) Vyšší produktivita framework ů spo čívá v již p ředepsaném kódu, který mohu libovoln ě implementovat do svého projektu, stejn ě jako v případ ě knihovny jQuery. Frameworky se dělí podle ú čelu, nap ř. na frameworky s využitím v architektu ře nebo v softwaru. Softwarové frameworky nadále d ělíme podle oboru využití (Wikipedia, 2016):

a) application framework b) content management framework c) web application framework d) multimedia framework

Framework ů pro PHP je velké množství. Analýza a porovnání p ředností a zápor ů framework ů by vysta čila na samostatnou práci. Část analýzy je provedena v práci Michala Sukup čáka Synopsy PHP Framework (Sukup čák, 2014, str. 10). Na technickém portálu SitePoint v článku The Best PHP Framework for 2015: SitePoint Survey Results jsou

7 Statistika je sou část práce jako p říloha č. 3 22 výsledky hlasování pro PHP frameworky podle oblíbenosti vývojá řů ve firemních a osobních projektech (Skvorc, 2015). Výsledky jsou sou částí práce jako p říloha č. 4.

Na t řetím míst ě se umístil framework Nette, který je dílem českých vývojá řů . Nette je oproti jiným framework ům mladým frameworkem, který se za čal vyvíjet v roce 2004, ale ve řejn ě byl k dispozici až v roce 2008 jako Open Source. Framework se aktivn ě vyvíjí a vycházejí u n ěj nov ější a modern ější verze tohoto frameworku. K dspozici má vlastní ladící nástroj Tracy . V české republice má tento framework velkou podporu ze strany vývojá řů i spole čností. Nabídek pro vývojá ře, kte ří umí pracovat s Nette, je na českém trhu obrovské množství.

Nevýhodou framework ů je jejich rozmanitost a časová náro čnost na orientaci v datové struktu ře, v architektu ře reprezentace dat a ve zvládnutí syntaxe. PHP frameworky se od sebe zna čně liší a p řechod z jednoho frameworku na jiný je náro čný. Kvalitn ě vyvíjet software ve frameworku zabere mnoho času, pokud nemá vývojá ř s frameworky žádnou zkušenost.

Souhrn vybraných technologií Design databázového rozhraní po číta čového slovníku je rozd ělen do t ří samostatných celk ů, které mezi sebou hierarchicky komunikují. Tzn., že uživatel, který zažádá o informace skrze GUI, p ředá dotaz aplika čnímu rozhraní a to následn ě komunikuje s DBS.

a) Databázový systém je realizován pomocí MariaDB. b) Skripty vykonávané na stran ě serveru, které jsou sou částí databázového rozhraní slovníku, jsou psány v jazyce PHP. c) Grafické uživatelské rozhraní slovníku je psané webovými technologiemi HTML, CSS a JavaScript.

3.2 Role a procesy

3.2.1 Role Obecn ě m ůžeme role d ělit na dv ě kategorie, a to na role aktivní a role pasivní. Rozdíl mezi těmito rolemi je v přístupu a práci se samotnou aplikací. Role aktivní mohou p římo ovliv ňovat informace v systému, kdežto role pasivní pouze informace ze systému obdrží. (Jalloul, 2004).

23

Pro stanovení rolí je d ůležité držet se obecných názv ů a nevytvá řet duplicitní role pouhým názvoslovím. Čím mén ě rolí pro aplikaci navrhneme, tím jednodušší a mén ě náro čný systém uživatel ů vytvo říme. Zárove ň to neznamená, že musíme role co nejvíce generalizovat a snažit se vytvo řit univerzální roli s velkým obsahem oprávn ění a proces ů. Cílem je eliminovat duplicitní role. Jednoduše lze zam ěnit roli redaktora a korektora, přičemž ob ě role mají v souvislosti s využitím proces ů v aplikaci totožný význam. Vytvo řením univerzální role editor se tak dostate čně vystihne význam obou t ěchto rolí a nemusíme mapovat procesy pro ob ě role zvláš ť.

U databázového rozhraní slovníku pracuji celkem s pěti rolemi. Aktivní role zastupuje administrátor, editor a p řihlášený uživatel. Pasivní roli představuje anonymní uživatel a aplika ční rozhraní třetích stran.

Administrátor je role s plným oprávn ěním k jakékoliv zm ěně v databázi i v samotném rozhraní, není nijak limitován. Roli editora zastupují uživatelé, kte ří jsou ur čeni k úpravám informací u pojm ů a na rozdíl od administrátora nemohou d ělat úpravy hromadn ě, schvalovat kategorie a m ěnit svá oprávn ění. Poslední aktivní rolí je p řihlášený uživatel, který má možnost nastavit si štítky a hodnotit pojmy. Všechny aktivní role mohou ve slovníku vyhledávat a p řidávat nové pojmy.

Mezi role pasivní pat ří jakýkoliv anonymní uživatel, který není p řihlášen. Takový uživatel má možnost vyhledávat ve slovníku a registrovat se. Pro hodnocení a nastavení štítk ů je anonymní uživatel vyzván k přihlášení. Aplika ční rozhraní třetích stran je speciální rolí pro získávání informací z databáze. Tato role se identifikuje na základ ě svého vygenerovaného api klí če, který je uložen v databázi slovníku. Jestliže ov ěř ení identity prob ěhne v po řádku, má t řetí strana možnost na čítat informace z databáze slovníku.

3.2.2 Procesy Proces je obecn ě definován jako souhrn n ěkolika díl čích krok ů k dosažení stanoveného cíle. Procesy p ři návrhu rozhraní popisujeme pomocí diagram ů v jazyce UML , angl. Unified Modeling Language. Syntax UML diagram ů je jednoduchá, diagram má podobu grafických primitiv.

Vizualizace procesu UML diagramem nemusí primárn ě sloužit pouze pro samotný vývoj, ale i pro potenciálního zákazníka, který z diagramu lépe pochopí celý pr ůběh procesu.

24

Proces se m ůže skládat z desítek jednotlivých krok ů, proto je vhodné pro lepší orientaci znázornit celý proces graficky .

Sekven ční UML diagram Jedním z druh ů UML diagram ů jsou sekven ční diagramy, ve kterých jsou p řesn ě popsány jednotlivé kroky v procesu. Stejný sekven ční diagram jsem použil na obrázku č. 2 pro znázorn ění proce su vkládání nového štítku do databáze p řihlášeným uživatelem .

Z obrázku č. 2 je patrné, jak celý proces p řidávání štítku uživatelem funguje, a v jakých krocích se zapojují jednotlivé části celého rozhraní. Takto mohu zmapovat všechny procesy pro konkrétní role a objasnit celý design databázového rozhraní .

Obrázek č. 2 – Sekven ční UML diagram pro p řidání pojmu uživatelem. Zdroj: Autor V prvním kroku kontroluji, zda je uživatel p řihlášen. Uživatelé, kte ří nejsou p řihlášeni, nemají možnost p řidávat štítky – nezobrazí se jim dialog pro p řidání štítku. V dalším kroku předá GUI dialog pro p řidání štítku, který obsahuje formulá ř s textovým polem, výb ěrem barvy a tla čítkem pro potvrzení. Jakmile uživatel odešle formulá ř, p ředají se informace ke zpracování databáz ovým rozhraním. Rozhraní kontaktuje databázový systém a p ředá získané informace z formulá ře. Databázový systém odpoví rozhraní nepravdu – FALSE .

25

Údaje zadané uživatelem neexistují, to je správn ě, jinak by nemohl být nový štítek p řidán. Rozhraní p ředá nový dotaz do databázového systému k vložení t ěchto údaj ů. V případ ě úsp ěchu vrátí databázový systém hodnotu TRUE , kterou rozhraní vyhodnotí jako úsp ěch , a předá GUI informaci, aby zobrazil upozorn ění pro uživatele, že štítek byl p řidán.

Use case diagram Další variantou vizualizace proces ů a rolí je UML diagram p řípad ů užití , angl. Use case diagram. Diagram p řípad ů užití nevyjad řuje jednotlivé kroky procesu tak, jako u sekven čních diagram ů, ale znázor ňuje všechny role, procesy a vztahy mezi nimi v jednom diagramu. Vztahy v tomto diagramu znázor ňují, jaké procesy má každá role přid ělené (Jalloul, 2004).

Obrázek č. 3 – Use Case diagram. Zdroj: Autor Obrázek č. 3 detailn ě popisuje, jaké role a procesy jsou pro databázové rozhraní slovníku navrženy. Každá role má p ři řazené své procesy, na které sm ěř uje ukazatelem šipky. Na pohled je z řejmé, že nap ř. anonymní uživatel má možnost registrovat se, vyhledávat a přidávat pojmy. Ostatní procesy nemá přid ělené, a proto je nem ůže využít.

26

3.3 Konceptuální a logický model databáze Návrh databáze se skládá z několika krok ů, ve kterých je t řeba ur čit, jaká data budou v databázi uložena, jakou budou mít strukturu a jaké jsou vzájemné vztahy mezi daty v databázi. Po t ěchto krocích mohu vytvo řit modely, které vyjad řují podobu datové struktury. Takové modely ozna čujeme jako konceptuální, logický a fyzický model.

Při konceptuálním modelování pracuji s analýzou dat a jejich reprezentací jako s objekty. Každý objekt má své vlastnosti - atributy a je propojen s jinými objekty pomocí vztah ů. Model m ůže mít hierarchickou, Entitn ě-Rela ční, zkrácen ě ER nebo i objektov ě- orientovanou podobu reprezentace dat. V záv ěru kapitoly č. 3.1.1 vybírám pro vlastní slovník databázový systém MariaDB, který má charakter rela ční databáze, tzn., že konceptuální model musí být v souladu s tímto systémem a má podobu Entitn ě-Rela čního schématu.

Návrh konceptuálního modelu provádím ve dvou fázích. Nejprve si nadefinuji seznam entit a následn ě vytvo řím ER diagram, kterým vyjád řím vztahy mezi entitami. Poté k entitám doplním jejich atributy a celé schéma normalizuji. Návrh konceptuálního modelu lze vytvo řit v jednom kroku již jako normalizovaný, záleží na osobní preferenci.

Seznam entit a jejich atribut ů:

Entita Atributy STITEK idStitek, nazev, barva, pismo, idUzivatel idUzivatel, jmeno, prijmeni, uzivjmeno, email, heslo, telefon, avatar, UZIVATEL www, narozen, vytvo řen, api_key, idRole ROLE idRole, nazev idPojem, nazev, zkratka, popis, vyklad, uroven, autor, vytvoren, POJEM schvaleno, schvalil, proces, verejne SYNONYM idPojem, synonym

KATEGORIE idKategorie, idNadrazene, nazev, verejne, schvaleno, schvalil

HODNOCENI idUzivatel, idPojem, hodnota

PROBLEM idProblem, nazev

OBSAH idObsah, nazev, odkaz, lokalne, pripona, verejne, idKategorie

OBEZNIK email, odebirat

CITACE idCitace, autor, titul, nakladatelstvi, isbn, citace

Tabulka č. 2 – Přehled entit a jejich atribut ů. Zdroj: Autor

27

Konceptuální model mohu vytvo řit softwarov ě, nebo nap ř. na papír, v obou p řípadech však musím dodržet stanovenou konvenci podoby diagramu použitím grafických primitiv. Pro modelování konceptuálního modelu využívám nástroj Draw.io , který je dostupný na adrese: http://draw.io. Draw.io je nástroj pro tvorbu diagram ů, schémat a technických návrh ů, jenž spolehliv ě nahradí komer ční i úzce specializované programy pro tvorbu konkrétního druhu diagramu. Dostupný je zdarma a online, export dat je v podob ě PDF, XML, HTML a SVG souboru nebo jako obrázek typu JPEG a PNG. Nástroj podporuje ukládání p římo na Google Drive, Dropbox, OneDrive, nebo na pevný disk. Konceptuální model v podob ě ER diagramu pro databázi slovníkové aplikace je sou částí p řílohy č. 5.

Teprve po vytvo ření konceptuálního modelu mohu vytvo řit logický model databáze. Logický model, na rozdíl od modelu konceptuálního, řeší už konkrétní podobu atribut ů. Tzn., že si v logickém modelu stanovím, jakým datovým typem jsou záznamy atributu, zda je atribut primárním nebo cizím klí čem, či nikoliv, definuji indexy aj. Logický model musím navrhnout vždy softwarov ě. Pro návrh logického modelu volím vývojové prost ředí MySQL Workbench Community edition.

MySQL Workbench je ve verzi Community edition voln ě dostupný a zdarma k použití na neomezenou dobu na všech nejznám ějších platformách. Tato verze plnohodnotn ě dosta čuje pro funkce, jakými jsou modelování databázového schématu, p řipojení k databázovému serveru a vytvá ření SQL skript ů. Dostupné jsou i další varianty nástroj ů pro modelování databázového schématu, jako nap ř. Database Workbench, SQLyog, HeidiSQL, dbForge Studio a další. V ětšina z nich jsou trialové verze, jejichž použití je zdarma na omezenou dobu, p řípadn ě s nutností registrace. Žádný z těchto nástroj ů mi p ři vytvá ření logického schéma nevyhovoval tak, jako MySQL Workbench.

Při tvorb ě logického schématu kontroluje MySQL Workbench r ůzné závislosti, jako jsou cizí klí če, nebo p ři vztahu s kardinalitou M:N automaticky vytvá ří další tabulku pro tento vztah. Grafické rozhraní tohoto nástroje je velmi příjemné a intuitivní. Proto jsem se rozhodl zvolit tento nástroj pro tvorbu logického schématu databáze.

Před založením nového logického schématu v MySQL Workbench je t řeba provést úpravy nastavení, ve kterém si nadefinuji nové chování programu p ři vytvá ření nových diagram ů, objekt ů a vztah ů mezi objekty. Každý výchozí model vytvo řený ve Workbench nástroji má zp ůsob ukládání tabulek v InnoDB engine , výchozí nastavení zm ěním na XtraDB , které MariaDB podporuje. O výhodách databázových engine u databázového systému MariaDB

28 pojednávám v kapitole č. 3.1.1. Workbench p ři vytvá ření cizích klí čů vytvá ří název cizího klí če s názvem tabulky, odkud pochází a v níž je primárním klí čem, nap ř. při vytvo ření cizího klí če idUzivatel do tabulky STITEK , se vytvo ří název cizího klí če UZIVATEL_idUzivatel. Toto nastavení upravuji, aby se vkládal pouze název klí če. Posledním nastavením je zm ěna chování p ři vytvá ření vztah ů M:N. Tabulka vytvo řená vztahem M:N má název složený z názv ů tabulek, k nimž vztah pat ří, a zárove ň obsahuje spojení _has_ , které není pot řebné.

Ačkoliv je MySQL Workbench ur čen pro databáze typu MySQL, mohu tento nástroj využít i pro tvorbu logického schématu pro MariaDB. Rozdíly v datových typech, kontrole cizích klí čů a jiných závislostí ošet řím nastavením chování programu, anebo úpravou SQL skriptu pro vytvo ření fyzického schématu databáze. Logické schéma databáze je sou částí přílohy č. 6.

29

4 Vývojové prost ředí V této kapitole se zabývám analýzou a výb ěrem vhodných softwarových nástroj ů pro vývoj databázového rozhraní. Popisuji, co jsou vývojová prost ředí a k čemu b ěhem vývoje slouží. U každého vybraného nástroje pak uvádím nastavení a základní klávesové zkratky pro efektivn ější práci s nástrojem.

Vývojová prost ředí , zkrácen ě IDE z angl. Integrated Development Environment, jsou softwarové nástroje, které usnad ňují práci vývojá ře p ři realizaci projektu, na kterém pracuje. Usnadn ění práce spo čívá ve využití široké škály integrovaných nástroj ů, kterými vývojové prost ředí disponuje. Nástroje mají své specifické vlastnosti a obsahují předp řipravené části modelu databáze nebo zdrojového kódu, které se při vývoji obecn ě používají.

IDE mají nástroje jako je editor, který představuje prázdné okno pro psaní zdrojového kódu, a kompilátor, jenž překládá napsaný zdrojový kód do strojového kódu. Následn ě se strojový kód spustí a ov ěř í se funk čnost zdrojového kódu, nebo může prost ředí využít přímého interpreta pro jazyk, ve kterém je zdrojový kód napsán, bez nutnosti kód p řekládat kompilátorem. N ěkterá IDE mají i ladící nástroje pro debugování, z angl. debugging. Debugování je proces analýzy a odstran ění chyb ve zdrojovém kódu. Chyby mají podobu překlep ů, nevalidní syntaxe, volání funkcí nebo prom ěnných, které nejsou definovány aj. Dalšími nástroji jsou nástroje pro testování a refaktorování kódu. Refaktorování kódu znamená úpravu kódu do čiteln ější podoby pro rychlejší a snazší orientaci v kódu, bez zásadních zm ěn samotných algoritm ů. Nejcenn ějším nástrojem ve vývojovém prost ředí je našeptávání kódu v editoru vývojového prost ředí. Našeptávání efektivn ě zkracuje dobu psaní kódu a zárove ň p ředchází zbyte čným chybám nebo p řeklep ům. P ři psaní zdrojového kódu v editoru nástroj našeptávání analyzuje část slova a nabídne mi možnosti kódu, které chci pravd ěpodobn ě napsat. Vývojové prost ředí za mě automaticky kontroluje, jestli nemám chybu v syntaxi a používám správné názvy t říd, prom ěnných aj. V případ ě, že mám chybu v kódu, upozorní prost ředí na tuto chybu v různých podobách, jako nap ř. podtržením textu nebo vyk řičníkem v řádku, kde se chyba nachází. Rozli čnost nástroj ů ve vývojovém prost ředí je rozdílná a každé prost ředí disponuje jinými nástroji s jinými vlastnostmi.

30

Zvolená vývojová prost ředí K vývoji databázového rozhraní je pot řeba kombinace n ěkolika vývojových prost ředí. Každé prost ředí má své specifické použití a teprve kombinací t ěchto prost ředí lze dosáhnout výsledku. Pro vývoj databáze využívám prost ředí MySQL Workbench. Dále však pot řebuji prost ředí pro realizaci zdrojového kódu databázového rozhraní, napsaného v jazyce PHP.

Mezi nejoblíben ější vývojová prost ředí pro psaní zdrojového kódu pat ří PhpStorm, Sublime Text, NetBeans a Zend Studio. To potvrzují i výsledky v článku Best PHP IDE in 2014 – Survey Results (Skvorc, 2014). Jasným výhercem je prost ředí PhpStorm, viz příloha č. 7, které disponuje všemi zmín ěnými nástroji v četn ě refaktoringu a testování kódu. PhpStorm je dostupný pro studenty v plné verzi zdarma po dobu jednoho roku od data registrace, a proto jsem se rozhodl nástroj využít k realizaci zdrojového kódu databázového rozhraní.

PhpStorm je náro čnější IDE na osvojení všech jeho funkcí, nástroj ů a klávesových zkratek. Prost ředí má obrovské možnosti nastavení a p řizp ůsobení si chování jednotlivých nástroj ů. Základní práce s programem je bez potíží. Mezi nejcharakteristi čtější rysy PhpStormu pat ří různé druhy vyhledávání, jako nap ř. Search everywhere , které umož ňuje vyhledávat v jakékoliv části prost ředí, a to i v nastavení programu a jeho vlastních zdrojových souborech. Dalšími možnostmi je vyhledávání t říd, funkcí, prom ěnných aj. V obou případech je možné vyhledávat pomocí syntaxe CamelCase, tzn., že zadaný výraz pro vyhledávání se skládá z několika slov spojených dohromady a každé po čáte ční písmeno spojeného slova je velké, viz NázHleVýraz – název hledaného výrazu.

Nejužite čnější funkcí, kterou v prost ředí PhpStormu využívám, je definování si vlastního kusu zdrojového kódu do nástroje našeptávání pomocí Live Templates . Vlastní kus kódu, který opakovaně využívám, vložím do vlastní šablony a pojmenuji ji vhodným názvem, pomocí něhož šablonu v našeptávání vyvolám a následn ě vložím obsah vlastního kódu v připravené šablon ě.

Další funkcí, kterou má editor PhpStormu, je Complete Statement . Tato funkce identifikuje blok kódu, v němž se nachází kurzor, a p ři stisku klávesové zkratky Ctrl+Shift+Enter funkce automaticky dokon čí celou část daného bloku, nap ř. složené závorky a st ředník.

31

5 Metody vývoje V kapitole metody vývoje se zabývám známými metodami, které se využívají p ři vývoji software. K vybraným metodám popisuji jejich charakteristiku a princip vývoje. K záv ěru kapitoly popisuji agilní metodu vývoje, kterou jsem si zvolil pro vývoj databázového rozhraní, a charakterizuji její st ěžejní vlastnosti.

Každý vývoj softwaru je vyvíjen n ějakými technikami, postupy či pravidly, souhrnn ě lze všechny tyto části sjednotit a ozna čit za metodu vývoje. N ěkteré metody vývoje jsou natolik populární, že pro n ě vznikají frameworky, které jsou rozvíjeny, podporovány a ší řeny spole čnostmi, jako nap ř. Rational Unified Proces od spole čnosti IBM, nebo komunitou vývojá řů , jako v případ ě Agile Unified Proces , kte ří tvo ří alianci agilních metodik.

Obecn ě se každá metoda vývoje skládá z paradigmatu, které je pro metodu charakteristické, a ze scéná ře, který tvo ří jednotlivé kroky vývoje. V dnešní dob ě d ělíme metody vývoje na dva hlavní proudy, jež jsou rigorózní, a agilní metodiky.

Každá metoda vývoje, a ť už spadá do proudu rigorózních, nebo agilních metod, má své klady a zápory vzhledem k vyvíjenému software. Vzhledem ke svým klad ům a zápor ům je každá metodika vývoje vhodn ější pro jiný druh vyvíjeného software. Nelze jednozna čně říct, že jedna metoda vývoje je lepší než druhá. Přesto je ze statistiky v článcích Stats: Project Methodologies 2011 a Stats: Project Methodologies 2013 zřejmé, že podíl agilních metodik roste oproti podílu rigorózních metod, které v článku zastupuje vodopádový model a V-Model (Young, 2012), (Young, 2013). Statistiky jsou sou částí p řílohy č. 9 a přílohy č. 10.

5.1 Rigorózní metody vývoje Pro rigorózní metody vývoje je charakteristické, že se striktn ě drží svých postup ů, a jakákoliv odchylka, jež není sou částí metody, je nežádoucí. Metody mají p řesn ě a podrobn ě definovaný proces vývoje, který lze opakovat. Požadavky na výsledný software jsou definovány p řed po čátkem vývoje a dle požadavk ů je sestaven plán realizace. U rigorózních metod má každý člen týmu p řid ělenou svoji roli, v níž zastává ur čené procesy, a proto je u každého člena týmu kladen d ůraz na specializaci. Pohled na člov ěka je

32 sekundární a zastává se názor, že každý je nahraditelný, a to díky rozsáhlé dokumentaci, která se b ěhem vývoje vytvá ří a je rovn ěž charakteristická pro rigorózní metody vývoje.

Mezi nejznám ější rigorózní metody pat ří:

a) vodopádový model b) prototypový model c) iterativní a inkrementální model d) V-Model e) spirálový model

5.2 Agilní metody vývoje Oproti rigorózním metodám vývoje je princip agilních metod opa čný, tzn., že jsou agilní metody flexibilní, snáze reagují na chybu nebo podnět od zákazníka a nemají problém se ihned p řizp ůsobit.

Pojem a princip agilních metod je poprvé sjednocen od roku 2001. V tomto roce je skupinou softwarových inženýr ů a vývojá řů sepsán manifest agilního programování . Manifest vychází jako kritika rigorózních metod vývoje a zam ěř uje se na čty ři základní hodnoty agilního vývoje software (Agille Alliance, 2001):

a) „Jednotlivci a interakce p řed procesy a nástroji b) Fungující software p řed vy čerpávající dokumentací c) Spolupráce se zákazníkem p řed vyjednáváním o smlouv ě d) Reagování na změny p řed dodržováním plánu“

U agilních metod vývoje je kladen d ůraz na čast ější dodávání funk čního softwaru a komunikaci se zákazníkem. Osobní setkání mezi členy týmu je považováno za nejefektivn ější formu komunikace. Jedinec v týmu je cenn ější než nástroj, nebo ť m ůže p ři analýze problému inspirovat ostatní a p řisp ět k rychlému nalezení řešení.

Agilní metody jsou spíše sadou doporu čení, jak p ři vývoji postupovat, než aby popisovaly jednotlivé kroky vývoje software, ty naopak agilní metody popírají. Postup vývoje agilní metodou probíhá v krátkých časových úsecích. Ve vývoji agilní metodou je kladen větší důraz na vyvíjený software, než na psaní dokumentace, a je vhodný pro vývoj v týmu, nežli pro jednotlivce.

33

Nejznám ější agilní metody vývoje jsou:

a) extrémní programování b) Scrum c) testy řízený vývoj d) vlastnostmi řízený vývoj e) Crystal

5.2.1 Extrémní programování Extrémní programování , zkrácen ě XP, je nejrozší řen ější agilní metodou vývoje. Princip extrémního programování spo čívá v co nejv ětší jednoduchosti. Programátor píše jen takovou část softwaru, která je práv ě vyžadována. XP p ředpokládá, že požadavky na software se budou b ěhem vývoje m ěnit, a proto nemá význam vyvíjet části software do budoucna. „XP dodává nejjednodušší možné verze, které jsou schopné provozu, verze dodává po velmi krátkých iteracích. “ (Popelka, 2014)

Pro XP je zásadní komunikace mezi všemi zainteresovanými subjekty, tzv. stakeholdery . V případ ě, že není zajišt ěna dobrá komunikace nap ř. se zákazníkem, m ůže vzniknout produkt, který nebyl o čekáván. Významným rysem pro XP je časté testování za pomocí automatizovaných test ů, programáto ři b ěhem vývojového cyklu neustále vytvá řejí a provádí jednotkové testy.

Extrémnost v této metod ě spo čívá v neustálém opakování činností, které se prokázaly jako přínosné pro vývoj, nap ř. již zmín ěné testování, jednoduchost, velmi krátké iterace aj. Autor metody XP Kent Beck popisuje, že p ři prvním vyslovení XP má vizi knoflík ů s ovládacím panelem. „Každý knoflík byl proces a ze zkušenosti jsem v ěděl, že to funguje dob ře. Obrátil jsem všechny knoflíky na 10 a sledoval, co se stane. Byl jsem p řekvapen, když jsem zjistil, že celý balík proces ů fungoval stabiln ě, p ředvídateln ě a flexibiln ě.“ (Beck, 1999).

5.2.2 Scrum Scrum , česky skrumáž, je agilní metoda vývoje, jež se orientuje na vývojový tým, který tvo ří jeden celek k dosažení stejného cíle a je jako celek odpov ědný za dodávané části produktu. Vývoj metodou Scrum probíhá v krátkých iteracích, jež nazýváme sprinty.

Sprint se skládá ze dvou částí, které p ředstavuje plánování sprintu a denní scrum . P ři plánování sprintu vývojový tým vybírá, jaké práce se za následující sprint ud ělají, tvo ří

34 backlog a p řipraví úkoly sprintu s časovým odhadem, jak dlouho bude trvat jejich spln ění. Další částí sprintu je denní scrum, který spo čívá v každodenním setkávání člen ů týmu. Denní scrum je n ěkdy ozna čován jako stand-up a smyslem tohoto setkávání je report dokon čených úkol ů nebo řešení problém ů, na které člen týmu p ři řešení úkolu narazil. Celý sprint trvá v rozmezí jednoho a ž tří týdn ů a b ěhem n ěj jsou vyvíjeny části produktu. Každý člen vývojového týmu si sám vybírá, na jaké část i bude pracovat. Grafická podoba procesu vývoje metodou Scrum je na obrázku č. 4.

Obrázek č. 4, Scrum process. Zdroj: Autor: Lakeworks https://commons.wikimedia.org/w/index.php?curid=3526338

35

6 Implementace databázového rozhraní V kapitole implementace databázového rozhraní popisuji postup implementace jednotlivých částí, ze kterých se skládá celé databázové rozhraní pro slovník. V jednotlivých pasážích textu se zabývám řešením problém ů, které se b ěhem implementace vyskytly, a text dopl ňuji vlastním řešením.

6.1 Příprava prost ředí k implementaci Pro vývoj a následné otestování databázového rozhraní si p řipravím prost ředí, ve kterém pob ěží části rozhraní slovníku. Prost ředí se skládá z databázového systému, v n ěmž je uložena báze dat s informacemi, jež tvo ří slovník, a z webového serveru s podporou PHP, který p řeloží skripty v jazyce PHP a p ředá vygenerovanou webovou stránku.

Takové prost ředí lze realizovat s instalovaným software MariaDB a IIS, které podporuje PHP skripty skrze modul CGI. V linuxovém prost ředí lze instalovat kombinaci software MariaDB, Apache a modul PHP. Instalace a konfigurace t ěchto softwarových částí je zdlouhavá a k vývoji databázového rozhraní volím již p řipravené řešení, jež je známé pod zkratkou XAMPP , která znamená, že je balík nezávislý na platform ě a obsahuje webový server Apache, databázový server MariaDB, modul pro zpracování skript ů v PHP a Perl.

Připravený balík aplikací XAMPP volím z toho důvodu, že obsahuje databázi MariaDB, kterou jiné, známé řešení s názvem WAMPServer nemá. XAMPP se dob ře ovládá přes kontrolní panel, který nabízí sadu tla čítek, pomocí nichž mohu přímo p řistupovat k editaci konfigura čních soubor ů, nebo každou část celého balíku postupn ě zapnout a ovládat. XAMPP zárove ň disponuje i logovacím oknem ve spodní části kontrolního panelu, které hlásí stavy celého prost ředí a jednotlivých částí.

Vlastní nastavení jednotlivých částí prost ředí XAMPP není nutné, protože balík je ve výchozím stavu p řipraven ihned k použití. Výchozí hodnoty jsou nastaveny pro lokální použití, jež práv ě pro vývoj rozhraní využívám.

6.2 Propojení prost ředí s nástroji pro vývoj Pro vkládání SQL dotaz ů, přes které komunikuji se S ŘBD, se musím p řipojit k databázovému serveru pomocí MySQL Workbench. Spojení MySQL Workbench zvolím na úvodní obrazovce programu výb ěrem MySQL Connections a vyplním základní údaje o připojení k databázovému serveru, který má při lokálním použití standardn ě adresu

36

127.0.0.1 s portem 3306 . Po p řipojení k databázovému serveru mám možnost psát SQL dotazy a komunikovat se serverem.

Prost ředí XAMPP musím propojit i s PhpStormem a to hlavn ě kv ůli absenci interpreta jazyku PHP v PhpStormu. Bez spojení PhpStormu s webovým serverem nemám možnost ov ěř it funk čnost svých PHP skript ů. V nastavení programu vyhledám položku s názvem Build, Execution, Deployment, poté následuje položka Deployment . V této položce provedu požadované nastavení. Přidám si nové spojení, které odkazuje na místní složku s projektem databázového rozhraní slovníku, ale soubory budu procházet skrze webový server na adrese http://localhost , jelikož využívám lokální server Apache, který je sou částí XAMPP.

6.3 Implementace databáze Při vytvo ření fyzického schématu databáze vycházím z návrhu logického schématu, realizovaného v MySQL Workbench. Nástroj Workbench má možnost vygenerovat SQL skript pro vytvo ření databáze. Skript je vygenerován na základ ě vztah ů, objekt ů a jejich atribut ů vytvo řených v logickém schématu.

U generování skriptu procházím dialogovým pr ůvodcem, ve kterém mám možnost nastavit další parametry skriptu. Zde si zvolím parametr, aby se mi p řed každým vytvo řením nové tabulky vytvo řil p říkaz na odstran ění tabulky stejného názvu, pokud již existuje. Workbench n ěkdy vytvo ří ve vygenerovaném skriptu dv ě shodné tabulky se stejnými názvy a atributy. V dalším kroku využívám filtr, kterým ur čuji, jaké objekty chci zahrnout do vygenerování skriptu, a následn ě nechám skript vygenerovat.

Vytvo řením fyzického schématu databáze pomocí vygenerovaného skriptu z MySQL Workbench narážím na potíže s kontrolou výchozích hodnot u atribut ů, které jsou u MySQL povoleny. MariaDB je však nepodporuje, proto jsem výchozí hodnoty u atribut ů ze skriptu odstranil. Dalším problémem je p ři použití SQL módu TRADITIONAL , jenž v mém p řípad ě blokuje vytvo ření záznam ů s nulovým datem. Proto tento parametr odstra ňuji a ponechávám parametr ALLOW_INVALID_DATES (MariaDB, 2012).

6.4 Problémy spojené s implementací Ve vlastní implementaci rozhraní slovníku využívám funkce jako registrace uživatele, přihlášení k odb ěru novinek nebo odeslání kontaktního formulá ře. Tyto funkce jsou vázané na PHP funkci mail() , která odesílá uživateli informace podle toho, jakou z uvedených

37 funkcí práv ě použil. P ři implementaci rozhraní na lokálním prost ředí nemohu PHP funkci mail() použít, nebo ť nemám dostupný mailserver.

Problém jsem se rozhodl vy řešit využitím webhostingu s vlastní doménou, který je dostupný na adrese http://pocitacovyslovnik.cz . Webhosting má stejný typ databáze a verzi PHP modulu jako prost ředí XAMPP, proto se nevyskytl žádný problém p ři přenesení soubor ů na webhosting.

38

7 Testování vlastní aplikace V kapitole testování vlastní aplikace popisuji d ůvody, pro č je testování aplikací d ůležité a jakými zp ůsoby lze aplikaci testovat. V kapitolách, jež se zam ěř ují na konkrétní zp ůsob testování, popisuji problematiku podrobn ěji a p řikládám vlastní vzor testu, který jsem aplikoval na implementované části databázového rozhraní.

Testování je nedílnou sou částí jakéhokoliv vývoje aplikací a slouží k odhalování chyb, které se b ěhem vývoje neúmysln ě vytvo ří. N ěkteré druhy test ů se provádí i u softwaru, jenž je již po n ějakou dobu využíván v praxi, a to proto, že s vývojem technologií se nachází nové metody, jak lez p ůvodn ě bezpe čný kód obejít.

Alespo ň základní testování aplikace vždy provádí během vývoje programátor, který postupn ě zkouší, zda aplikace funguje správn ě a zobrazuje o čekávané výsledky. Tato metoda testování je nejzákladn ější sou částí procesu testování aplikace.

Celý proces testování je komplexní a rozd ěluje se do n ěkolika etap, ve kterých provádí testování pokaždé jiný subjekt. Celý proces d ůkladného testování je časov ě náro čný a může trvat i déle než samostatný vývoj aplikace. Z toho d ůvodu se v některých projektech ur čité etapy testování úmysln ě vynechají, aby nebyl výsledný produkt levn ější. Zárove ň to znamená vyšší procento chyb v aplikaci, protože vynechané etapy testování tyto chyby neodhalí, a v důsledku m ůže v provozu neotestovaná aplikace napáchat v ětší škody, nežli vyšší cena samotného produktu s provedenými testy.

Cílem testování je odhalit co nejv ětší po čet chyb a ty následn ě opravit, aby mohl být výsledný produkt považován za spolehlivý a použitelný. Chyba znamená jakékoliv neo čekávané chování aplikace, které vede k jinému než očekávanému stavu. Ten m ůže představovat pád samostatné aplikace nebo poškození zdrojových dat. Z tohoto d ůvodu je důležité provád ět testování aplikace ve zvláštním testovacím prost ředí, které je kopií vyvíjeného produktu, aby nedošlo k nevratným zm ěnám. Zárove ň je vhodné testované části aplikace verzovat.

Verzování aplikace znamená uchovávat historii provedených zm ěn ve zdrojovém kódu nebo sad ě soubor ů aplikace či databáze. Pro verzování využíváme systém správy verzí , zkrácen ě VCS z angl. Version Control System. VCS systém m ůže mít podobu lokální pro verzování na lokální úrovni, centralizovanou pro verzování nap ř. v týmu, nebo

39 distribuovanou, kterou je možné rovn ěž použít pro verzování v týmu s tím rozdílem, že každý napojený uživatel u sebe uchovává kompletní kopii celého repozitá ře. Známé VCS systémy jsou Git, Mercurial, Subversion, Perforce aj (Chacon a Straub, 2016). Verzování vlastního projektu je možné p římo z vývojového prost ředí PhpStorm, které podporuje zmín ěné VCS systémy.

Vlastní testovací prost ředí není jen z důvodu p ředcházení poškození nebo ztráty dat, ale i kv ůli možnosti simulace r ůzných druh ů stavu systému, jako nap ř. úmysln ě chybná data, čímž testujeme, jak se aplikace k takové chyb ě zachová a zda správn ě projeví chybu v té části aplikace, která je práv ě testována, nebo zda se chyba nap říklad neprojeví v ůbec. Jestliže se chyba vůbec neprojeví, p řestože aplikaci chybí data, můžeme takový stav rovn ěž ozna čit za chybný.

Přípravu takového prost ředí má na starost ur čený tester, který musí být schopen takové prost ředí vytvo řit a um ět mimo řádné stavy nasimulovat. Tester musí být technicky zdatný, aby si dokázal prost ředí vytvo řit, um ěl pracovat s doprovodnými částmi aplikace, jako nap ř. databázový systém, aby v něm mohl provést nap ř. zám ěnu dat a zárove ň být zdatný v programování, aby porozum ěl kódu aplikace. Nejcenn ější vlastností testera je silné analytické myšlení a grafické a funk ční cít ění.

Je patrné, že takových tester ů nebude mnoho, a to je rovn ěž jeden z důvod ů, pro č se celý proces testování d ělí do n ěkolika částí, v nichž každý tester, který je sou částí v ětšího týmu, plní vlastní podstatnou úlohu. Celý „tento proces se nazývá řízení jakosti neboli kvality“ (Míka, 2013, str. 3).

Testování tedy m ůžeme rozd ělit do 7 samostatných částí podle druhu provád ěných test ů (Hlava, 2011):

a) testování programátorem b) jednotkové testování c) funk ční testování d) integra ční testování e) systémové testování f) akcepta ční testování g) penetra ční testování

40

Testování programátorem probíhá ve chvíli, kdy programátor sestaví část zdrojového kódu a automaticky ov ěř uje, že daná část funguje podle p ředpoklad ů. Tomáš Hlava uvádí ve svém článku Fáze a úrovn ě provád ění test ů, že m ůže jít o tzv. test čty ř o čí, kdy programátor netestuje sám sebou vytvo řený kód, ale p ředá kód ke kontrole jinému programátorovi, který hledá chyby. Zárove ň uvádí, že „v praxi je bohužel tento stupe ň testování často podce ňován. P řitom oprava chyb v této části testování software je nejméně nákladná.“ (Hlava, 2011). Takový zp ůsob testování, resp. kontroly, můžeme aplikovat v případ ě, kdy se na vývoji aplikace podílí více než jeden programátor.

V následujících kapitolách se v ěnuji z mého pohledu nejd ůležit ějším částem celého procesu testování s ohledem k vlastnímu vývoji databázového rozhraní slovníku, který má podobu webové aplikace.

7.1 Jednotkové testy V této části testování jde o sestavení jednotkového testu, angl. Unit test, který kontroluje tzv. jednotky. Ty představují část zdrojového kódu aplikace, kterou nap ř. v případ ě objektov ě orientovaného programování reprezentuje dle rozsahu zdrojového kódu samostatná t řída nebo metoda. Test má podobu programového kódu, proto tuto část testování nej čast ěji vykonává programátor. P říprava takových test ů m ůže dokonce trvat i déle než samotný vývoj aplikace.

„Jednotkový test je tedy v podstat ě část kódu, který aktivuje jednotku a kontroluje výsledek jednoho specifického konce testované jednotky. Pokud je p ředpokládaný konec výsledku špatný, test jednotky selhal.“ (Osherove, 2014, str. 5) Tzn., že poté musí programátor nebo vývojá ř najít chybnou část jednotky, tu následn ě opravit a spustit test znovu.

Vytvo ření kvalitního jednotkového testu je náro čné na čas. Vzhledem k t ěmto nárok ům, které jsou pro vytvo ření jednotkových test ů vyžadovány, je efektivní provád ět tento typ testu již v po čátku vývoje aplikace, protože „testy jednotek se velmi špatn ě aplikují na již zab ěhlých projektech. U již vytvo řených aplikací se v ětšinou musí provést kompletní refaktoring kódu, či dokonce mnohem hlubší úpravy.“ (Hlava, 2011).

Práv ě tento test je nejvhodn ější metodou ov ěř ení funk čnosti refaktorovaného kódu. V principu je nejprve sestaven jednotkový test, který ov ěř í bezchybné fungování funk ční jednotky aplikace. Poté p řejde programátor po malých krocích k refaktorování kódu

41 jednotky, a následn ě testem op ět ov ěř í, jestli se funk čnost stejné jednotky aplikace nezm ěnila a je stále bezchybná.

Pro ov ěř ení vlastní části rozhraní slovníku rovn ěž využívám jednotkový test. Test je sestaven pomocí vývojového prost ředí PhpStorm, které umož ňuje sestavit si a asociovat jednotkový test ke konkrétní jednotce. PhpStorm disponuje frameworkem PHPUnit pro testování jednotek a nabízí možnost vkládání p ředepsaných blok ů pro sestavení testu.

Stejn ě jako v případ ě vývoje aplikace, i pro jednotkové testy se nabízí řady framework ů. Pro jazyk PHP je dostupný framework PHPUnit. Ú čel frameworku je stejný jako v případ ě vývoje aplikace.

Jednotkový test se obecn ě skládá ze t ří částí (Osherove, 2014, str. 24):

a) Aranžování objekt ů, jejich vytvo ření a nastavení, což znamená, že si vytvo říme objekt, na kterém provedeme test, a nastavíme si pro n ěj vstupní a výstupní prom ěnné. b) Vykonání testu – provedeme samostatný test s metodou, kterou práv ě testujeme. c) Tvrzení n ějakého výsledku, jenž je o čekáván – vytvo říme platné tvrzení, které je bezchybné pro testovanou metodu, a porovnáme tvrzení s výsledkem testované metody.

V následující ukázce je podoba jednotkového testu vytvo řeného s pomocí testovacího frameworku PHPUnit. Framework PHPUnit je již sou částí PhpStormu.

// Aranžování testu public function setUp() { $this>vysledek = new Passgen($this>delkahesla,$this>vysledek); }

// Provedení testu a tvrzení předpokladu public function testDelkyHesla() { return $this>assertSame($this>delkahesla, strlen($this>vysledek>passgen($this>delkahesla))); } } ?>

Test je zam ěř en na otestování metody passgen() , která slouží ke generování textového řet ězce, jenž p ředstavuje heslo. Vstupní hodnota pro metodu passgen() je celé číslo, které

42 ur čuje délku výstupního řet ězce. Cílem testu je ov ěř it, že metoda vrací textový řet ězec a ve stejné délce, v jaké je požadován. Nejprve si z třídy Passgen, která obsahuje testovanou metodu, vygeneruji novou t řídu TestPassgen, do níž si importuji t řídu Passgen, jinak test nem ůže ov ěř it funk čnost metody v této t říd ě. Poté si nastavím vstupní a výstupní prom ěnné s názvem $delkahesla a $vysledek , naaranžuji test metodou setUp() , a následn ě vytvo řím testovací metodu s názvem testDelkyHesla() , ve které aplikuji tvrzení, že prom ěnná $delkahesla se rovná délce vytvo řeného řet ězce metodou passgen() . Podoba metody passgen() je sou částí p řílohy č. 8.

Správný výsledek takového testu vypadá takto:

Testing started at 15:33 ...

PHPUnit 3.7.21 by Sebastian Bergmann.

Time: 0 seconds, Memory: 1.75Mb

OK (1 test, 1 assertion)

Process finished with exit code 0

Kompletní problematice jednotkových test ů se v ěnuje autor Roy Osherove ve své publikaci the Art of Unit Testing (Osherove, 2014). Kniha je velmi čtivá, zábavná a obsahuje praktické p říklady a pohled na testování jednotek.

7.2 Funk ční testy Oproti jednotkovým test ům, ve kterých se postupn ě testují samostatné t řídy a jejich metody, mají funk ční testy , zkráceně FAT z angl. Factory Acceptance Test, mají předepsané sady vstup ů a na základ ě t ěchto vstup ů ov ěř ují, že aplikace vrací správné výstupy. „Tester p ředkládá softwaru p řipravená vstupní data s tím, že dle specifikace předem zná výstupní data, a ov ěř uje, že software tato výstupní data opravdu vytvo řil“ (Míka, 2013, str. 7). Specifikace je zadání zákazníka s vý čtem funkcí, kterými má výsledný software disponovat, a jaké jsou o čekávané výsledky t ěchto funkcí.

Testerem připravená vstupní data jsou vytvá řena na základ ě kombinací, se kterými se aplikace m ůže setkat. Po čtů kombinací vstupních dat, které lze aplikaci p ředložit, je obrovské množství, proto není možné v této fázi testování ov ěř it všechny kombinace vstupních dat a musíme vybrat jen takovou množinu test ů, která adekvátn ě odpovídá pravd ěpodobným vstup ům p ři b ěžném používání aplikace. Z tohoto d ůvodu jsou funk ční

43 testy nejrozsáhlejší a nejnáro čnější fází celého procesu testování a v této fázi se odhalí nejv ětší množství chyb.

Netestuje se pouze správné fungování implementovaných funkcí samotné aplikace, ale testuje se také, zda má aplikace opravdu i funkce, které jsou vyžadovány zákazníkem.

V případ ě vlastního databázového rozhraní slovníkové aplikace se zam ěř uji na testování:

a) validity zdrojového kódu b) kontrole funk čních odkaz ů c) kontrole formulá řových polí

Cílem ov ěř ení validity zdrojového kódu je prokázat, že se v rozhraní slovníku nevyskytuje syntaktická chyba nebo nechybí část zdrojového kódu, protože v případ ě chyb ějící párové zna čky HTML bude rozhraní slovníku fungovat. Pro ov ěř ení využívám nejznám ější valida ční službu Markup Validation Service vytvo řenou World Wide Web konsorciem, známým pod zkratkou W3C. Služba je dostupná online na adrese https://validator.w3.org a umož ňuje validaci HTML, CSS, SVG a jiných dokument ů v nejb ěžn ějších verzích.

Ke kontrole funk čních odkaz ů lze rovn ěž využít online nástroj Online Broken Link Checker , dostupný na adrese www.brokenlinkcheck.com, nebo sofistikovan ější nástroj Xenu , který nekontroluje pouze aktivní odkazy, jež se zobrazují uživateli, ale i validitu odkaz ů na externí zdroje a soubory, jimiž mohou být styly, knihovny, obrázky nebo videa, atp. Xenu test odhalí, zda jsou všechny odkazy správn ě nadefinované, aktivní a funk ční. V případ ě pozitivního výsledku je jisté, že se uživatel aplikace vždy dostane tam, kam vede odkaz. Nástroj Xenu je freeware, dostupný zdarma na dobu neur čitou a bez nutné registrace.

Další částí funk čního testování je kontrola formulá řových polí. Kontrola spo čívá v ov ěř ení správné reakce formulá řových polí na vstupní data od uživatele, nap ř., že formulá ř správn ě reaguje na špatn ě vypln ěný tvar pole jako v případ ě emailu. Test je zam ěř en i na ov ěř ení funk čnosti formulá ře, zda prob ěhne validace formulá řových polí a odeslání. K tomuto typu testu existují softwarové nástroje v podob ě dopl ňků pro prohlíže č. Nejznám ějším dopl ňkem je Firefox Web Developer Toolbar . Nástroj m ě p říliš nenadchnul, přestože má mnoho zajímavých funkcí, nap ř. nabízí zdrojový kód k formulá řovým polím, jehož je vhodný doplnit, aby byla zaru čena stoprocentní funk čnost formulá řového prvku s prohlíže čem.

44

Dalším nástrojem pro realizaci funk čních test ů je Selenium IDE , také v podob ě dopl ňku pro prohlíže č Firefox. Nástroj umož ňuje sestavení testu pomocí nahrávání vlastního postupu p ři procházení databázovým rozhraním. Po ukon čení nahrávání se zapíší jednotlivé kroky jako itinerá ř celého testu. Takto sestavený test se následn ě spustí s hodnotami, které byly zaznamenány p ři nahrávání testu, čímž se zjistí, zda rozhraní slovníku vykazuje o čekávané hodnoty p ři zm ěně vizuální, nebo funk ční části aplikace.

Sestavený funk ční test je sou částí p řílohy č. 11. V ukázce testu ov ěř uji, jestli probíhá kontrola zadaných hodnot do formulá ře ur čeného pro registraci uživatele a zda je v případ ě zadání neplatných hodnot uživatel vyzván k oprav ě údaj ů.

7.3 Penetra ční testy Poslední etapou procesu testování jsou penetra ční testy. Smysl těchto test ů spo čívá v testování stability a odhalení neošet řených chyb ve zdrojovém kódu aplikace, aby případný úto čník nemohl implementovat vlastní část kódu, tzv. exploit . Exploit jsou programy nebo p říkazy, kterými úto čník vykonává jinou než původn ě zamýšlenou činnost napadené aplikace.

Tyto testy p ředchází potenciálnímu úniku informací v podob ě osobních údaj ů, know-how a dalších citlivých, d ůvěrných a zneužitelných informací. Testy zárove ň zvyšují důvěryhodnost zákazník ů nebo uživatel ů, kte ří aplikaci využívají. Realizace test ů je provád ěna externím subjektem, jenž se snaží do aplikace proniknout r ůznými zp ůsoby.

Testy mohou mít podobu:

a) Zadávání falešných p řihlašovacích údaj ů – zjiš ťujeme, zda je aplikace chrán ěna proti bot ům8 a zda jsou nastaveny maximální limity pro opakované p řihlašování. b) Odposlechu informací v případ ě nezabezpe čeného p řenosu – takové informace lze analyzovat a získat p řihlašovací údaje uživatel ů nebo ke správ ě aplikace. c) Simulace bot ů, které se snaží proniknout skrze formulá řová pole – jestliže nejsou formulá řová pole maximáln ě zabezpe čena, m ůže být zákazník cílem spamu. d) Získání informací pomocí SQL injection – test spo čívá v zadávání SQL dotaz ů do formulá řových polí, čímž se testuje, zda jsou formulá řová pole dostate čně ošet řena, a útočník nem ůže získat citlivé informace z databáze vlastním SQL p říkazem.

8 Boti jsou robotické programy, které mají jistou míru autonomie, prozkoumávají internet a získávají obsah, ke kterému by za normálních okolností nem ěly mít p řístup. 45

e) Zadávání částí JavaScriptového kódu do formulá řových polí – test je nazýván XSS z angl. cross site scripting. Úto čník zkouší vložit vlastní kód do aplikace.

Penetra ční testy se doporu čují opakovat v rozumném časovém horizontu, nebo ť s rychlým vývojem technologií se objevují nové metody, jak zneužít bezpe čnostní chyby v aplikaci, která již penetra čními testy prošla.

K otestování vlastního databázového rozhraní penetra čními testy jsem využil online nástroj Detectify: Go Hack Yourself , který je dostupný na adrese http://detectify.com. Nástroj nabízí po dobu 21dní monitoring databázového rozhraní na vlastním webhostingu přístupném ve řejn ě. Webhosting je nejprve t řeba ov ěř it, to lze nap říklad pomocí DNS záznamy, meta zna čkou v hlavi čce HTML dokumentu, nebo zkopírováním vygenerovaného souboru do webhostingu. Po ov ěř ení je dostupný test, který se skládá celkem ze 7 fází. Po čáte ční fáze slouží k získávání co nejvíce možných informací o zadané domén ě a tyto informace jsou následn ě použity pro p ředposlední fázi, ve které se aplikují penetra ční testy a odhaluje se zranitelnost aplikace. V poslední fázi se nachází dostupný přehled analýzy se seznamem zranitelných míst s ozna čením závažnosti. Celý test trvá několik hodin, záleží na rozsáhlosti aplikace.

Pokud jsem si jist, že má aplikace nemá zranitelná místa, mohu nechat své rozhraní otestovat zkušenými programátory v Bounty programu . Princip Bounty programu spo čívá v umíst ění nabídky pro programátory, kte ří se snaží v aplikaci odhalit slabá místa. V případ ě, že se to žádnému z programátor ů nepoda ří, je aplikace bezpe čná. V jiném případ ě programátor popíše zranitelné místo, které využil, a získá svou odm ěnu.

46

8 Záv ěr Cílem práce bylo analyzovat existující řešení po číta čových slovník ů a dle analýzy navrhnout vlastní řešení, které doplní zjišt ěné nedostatky, následn ě vlastní řešení implementovat a popsat pr ůběh implementace, otestovat a vysv ětlit význam t ěchto test ů. Díl čím cílem práce bylo popsat, v jakých krocích probíhá vývoj databázového rozhraní, jaké technologie lze k vývoji použít a pomocí jakých metod rozhraní vyvíjet.

8.1 Zhodnocení dosažení cíl ů Analýza prokázala, že žádný z dostupných řešení po číta čových slovník ů nevyhovuje sledovaným parametr ům uvedeným v kapitole č. 1.1, a proto jsem navrhnul vlastní řešení, které p řináší uživatel ům více funkcí a možností, jak s po číta čovým slovníkem pracovat.

Vlastní návrh rozhraní je obohacen o funkce, registraci uživatele, p řidávání pojm ů do databáze slovníku, využití štítk ů k seskupování pojm ů podle vlastních kritérií, hodnocení pojmu, hlášení chyb a rozší řené možnosti vyhledávání, u kterého lze vyhledávat podle názvu pojmu, kategorií, štítku a jména autora. Vyhledávání je kombinováno v nalezení přesného výskytu výrazu, p řípadn ě mnohonásobného výskytu s fulltextovým vyhledáváním. Vlastní návrh rozhraní slovníku tedy spl ňuje sledované parametry.

Práce je strukturovaná do kapitol, které čtená ři prezentují jako hlavní body vývoje databázového rozhraní. V každé z kapitol popisuji základní problematiku, analyzuji dostupné možnosti a na záv ěr předkládám vlastní rozhodnutí. Práce tak nabízí čtená ři úvodní vhled do problematiky vývoje databázového rozhraní s možnostmi, které m ůže využít ve vlastním vývoji rozhraní.

8.2 Výstupy práce Hlavním výstupem práce je funk ční databázové rozhraní pro po číta čový slovník, které bylo vyvíjeno v souladu s touto prací. Rozhraní je dostupné online na adrese http://pocitacovyslovnik.cz . K prozkoumání funkcí je vytvo řen testovací uživatel, který má p řihlašovací údaje: [email protected] a heslo Kolecko123 .

Vzhledem k použitým technologiím pro vývoj slovníkové aplikace má tato aplikace potenciál se dál vyvíjet. Rozhraní m ůže být rozší řeno o další možnosti nap ř. o vyhledávání podle času vytvo ření pojmu, nebo m ůže být slovník dostupný jako mobilní aplikace.

47

Databázové rozhraní pro po číta čový slovník bude i nadále vyvíjeno a rozši řováno o další funkce pro uživatele, budou p řidávány další pojmy s výkladem, aby online slovník splnil své cíle stát se nejvyhledávan ější a nejv ětší databází pojm ů v oboru informa čních a komunika čních technologií.

8.3 Záv ěre čné shrnutí práce V této práci jsem m ěl možnost rozší řit a prohloubit si své znalosti týkající se problematiky vývoje databázového rozhraní, a navázat tak na znalosti získané b ěhem studia. P ři řešení vývoje a implementace databázového rozhraní jsem získal praktické zkušenosti s nastavením a prácí s vývojovým prost ředím PhpStorm, které jsem si po chvilce oblíbil. Zkušenosti jsem získal i p ři řešení potíží s implementací databáze a databázového rozhraní, kdy jsem musel nastudovat dokumentaci a problém vy řešit. Našt ěstí se nevyskytl žádný problém, který by byl pro implementaci vlastního rozhraní fatální.

Jako nejzajímav ější část práce shledávám kapitolu v ěnovanou testování, ve které jsem si nastudoval a následn ě prakticky vyzkoušel, jak se testy vytvá řejí a jak funguje jejich aplikace v praxi.

48

9 Seznam použitých informa čních zdroj ů 1. WINKLER, Petr. Velký po číta čový lexikon. 1. vyd. Praha: Computer Press a.s., 2009. ISBN: 978-80-251-2331-7 2. VORÁ ČEK, Rudolf. Slovník po číta čových pojm ů a zkratek. 2. vyd. Praha: Fortuna, 1998. ISBN: 80-7168-590-9 3. ŘÍHA, Petr. Slovník po číta čové informatiky: Výkladový slovník pro práci s informacemi. 1. vyd. Ostrava: MONTANEX a.s., 2002. ISBN: 80-7225-083-3 4. NÁDB ĚLA, Josef. Velký po číta čový slovník. 2. vyd. Kralice na Hané: Computer Media s.r.o., 2006. ISBN: 80-86686-56-6 5. Creative Commons Česká republika. Úvod do CC [Online]. © 2016 [cit. 2016-02- 22] Dostupné z: 6. ŠEDA, Miloš. Databázové systémy . Brno: VUT, 2002. Dostupné z: 7. CELKO, Joe. Complete guide to NoSQL: What every SQL professional Leeds to know about Nonrelational databses. 1. st. Waltham: Elsevier Inc., 2014. ISBN: 978-0-12-407192-6 8. DATE, J. Christopher. SQL and Relational Theory: How to Write Accurate SQL Code. 2. nd. Sebastopol: O'Reilly Media Inc., 2011. ISBN: 978-1-449-31640-2 9. KOŠÁREK, Lukáš. Výkonnostní srovnání rela čních databází. Bakalá řská práce. Masarykova Univerzita, Fakulta informatiky, Brno 2010. 10. LINDSTROM, Jan. Performance evaluation of MariaDB 10.1 and MySQL 5.7.4- labs-tplc [Online]. © 2014 MariaDB Foundation [cit. 206-02-20] Dostupné z: mysql-5-7-4- labs-tplc/> 11. SCHWENKE, Axel . MariaDB 10.1 and MySQL 5.7 performance on commodity hardware [Online]. © 2015 MariaDB Foundation [cit. 2016-02-20] Dostupné z: 12. Percona LLC. The Percona XtraDB Storage Engine [Online]. © 2016 [cit. 2016- 02-20] Dostupné z: 13. MariaDB Corporation. Aria Storage Engine [Online]. © 2010 [cit. 2016-02-20] Dostupné z:

49

14. RUTTER, Jake. SMASHING jQuery . 1 st. West Sussex: John Wiley & Sons Ltd., 2011. ISBN: 978-0-470-97723-1 15. DAVID, Matthew. HTML5: Design Rich Internet Applications . 2. nd. Indiana: Focal Press, 2013. ISBN: 978-0-240-82076-7 16. RIEHLE, Dirk. Framework Design: A Role Modeling Approach. Ph.D. Thesis, No. 13509. Zürich, Switzerland, ETH Zürich, 2000. Dostupné z: 17. WIKIPEDIA CONTRIBUTORS. Framework [online]. © 2016 [cit. 2016-02-21]. Dostupné z: 18. W3Techs. Usage of server-side programming languages for websites [Online]. © 2016 Q-Success [cit. 2016-02-27]. Dostupné z: 19. SKVORC, Bruno. The Best PHP Framework for 2015: SitePoint Survey Results [Online]. © 2015 SitePoint Pty. Ltd. [cit. 2016-02-21] Dostupné z: 20. SUKUP ČÁK, Michal. Synopsy PHP Framework . Diplomová práce. Masarykova Univerzita, Fakulta informatiky, Brno 2014. 21. JALLOUL, Ghinwa. ULM by Example. 1. st. Cambridge: CAMBRIDGE UNIVERSITY PRESS, 2004. ISBN: 0-521-00881-6 22. MariaDB. Knowledge Base: SQL_MODE [Online] © 2012 MariaDB [cit. 2016-04- 12] Dostupné z: 23. CHACON, Scott a STRAUB, Ben. Pro Git [Online]. © 2016 Apress [cit. 2016-04- 12] Dostupné z: < https://progit2.s3.amazonaws.com/en/2016-03-22-f3531/progit- en.1084.pdf> 24. YOUNG, Blake. Industry Stats: Project Methodologies 2011 [Online]. © 2012 Planit [cit. 2016-04-12] Dostupné z: 25. YOUNG, Blake. Industry Stats: Project Methodologies 2013 [Online]. © 2013 Planit [cit. 2016-04-12] Dostupné z:

50

26. PADDA, Sheilly. Review of Software Development Methodologies Used in Software Design [Online]. © 2014 Warse [cit. 2016-04-12] ISSN: 2278-3091 Dostupné z: < http://warse.org/pdfs/2014/ijatcse02352014.pdf> 27. Agile Alliance. Manifesto for Agile Software Development [Online]. © 2001 Agile Alliance [cit. 2016-04-12]. Dostupné z: 28. POPELKA, Vladimír. Srovnávací analýza metodik vývoje software . Bakalá řská práce. Vysoká škola ekonomická v Praze, Fakulta informatiky a statistiky, Praha 2014. 29. BECK, Kent. Extreme Programming Explained [Online]. © 1999 Ken Beck [cit. 2016-04-12] ISBN: 0201616416 Dostupné online z: 30. OSHEROVE, Roy. The Art of UNIT TESTING. 2. nd. Shelter Island: Manning Publications Co., 2014. ISBN: 978-1-617290-89-3 31. SKVORC, Bruno. Best PHP IDE in 2014 – Survey Results [Online]. © 2014 SitePoint Pty. Ltd. [cit. 2016-03-18] Dostupné z: 32. MÍKA, Tomáš. Návrh nového p řístupu k řízení kvality p ři vývoji software . Diplomová práce. Brno: Masarykova univerzita, Fakulta informatiky, 2013. 33. HLAVA, Tomáš. Fáze a úrovn ě provád ění test ů [Online]. © 2011 Tomáš Hlava. [cit. 2016-03-19] Dostupné z:

51

10 Seznam p říloh 1. DB-Engines Ranking. Zdroj: http://db-engines.com/en/rating 2. Propustnost rela čních SQL systém ů 1 – 200 vláken na serveru. Zdroj Košárek, 2010 3. Usage of server-side programming languages for websites. Zdroj: W3Techs: http://w3techs.com/technologies/overview/programming_language/all 4. PHP Framework Popularity in Personal Projects. Zdroj: SitePoint: http://www.sitepoint.com/best-php-framework-2015-sitepoint-survey-results/ 5. Konceptuální model – ER diagram databáze slovníkové aplikace. Zdroj: Autor 6. Logický model databáze slovníkové aplikace. Zdroj: Autor 7. Best PHP IDE in 2014 – Survey Results: Personal choice. Zdroj: SitePoint http://www.sitepoint.com/best-php-ide-2014-survey-results/ 8. Podoba t řídy Passgen s metodou passgen(). Zdroj: Autor 9. Planit Testing Index 2011: Project Methodologies . Zdroj: Planit https://www.planittesting.com/au/Insights/2012/Industry-Stats-Project- Methodologies-2011 10. Planit Testing Index 2013: Software Development Projects by Methodology . Zdroj: Planit https://www.planittesting.com/us/Insights/2013/Industry-Stats- Project-Methodologies-2013 11. Funk ční test formulá ře k registraci uživatele provedený v Selenium IDE. Zdroj: Autor

52

11 Přílohy

Příloha č. 1 DB-Engines Ranking [cit. 2016-04-10]. Zdroj: http://db-engines.com/en/rating

Příloha č. 2, Propustnost rela čních SQL systém ů 1 – 200 vláken na serveru. Zdroj Košárek, 2010

53

Příloha č. 3, Usage of server-side programming languages for websites [cit, 2016-02-27]. Zdroj: W3Techs: http://w3techs.com/technologies/overview/programming_language/all

Příloha č. 4, PHP Framework Popularity in Personal Projects [cit. 2016-02-22]. Zdroj: SitePoint: http://www.sitepoint.com/best-php-framework-2015-sitepoint-survey-results/

54

Příloha č. 5 , Konceptuální model – ER diagr am databáze slovníkové aplikace. Zdroj: Autor

Příloha č. 6 , Logický mod el databáze slovníkové aplikace. Zdroj: Autor

55

Příloha č. 7, Best PHP IDE in 2014 – Survey Results: Personal choice [cit. 2016-03-18]. Zdroj: SitePoint http://www.sitepoint.com/best-php-ide-2014-survey-results/

Příloha č. 8, Pohoda t řídy Passgen a její metody passgen(). Zdroj Autor

56

Příloha č. 9, Planit Testing Index 2011: Project Methodologies. [cit. 2016-04-12] Zdroj: Planit https://www.planittesting.com/au/Insights/2012/Industry-Stats-Project-Methodologies-2011

Příloha č. 10, Planit Testing Index 2013: Software Development Projects by Methodology. [cit. 2016-04-12] Zdroj: Planit https://www.planittesting.com/us/Insights/2013/Industry-Stats-Project-Methodologies-2013

57

Příloha č. 11, Funk ční test formulá ře k registraci uživatele provedený v Selenium IDE. Zdroj: Autor

58