Ing. Michal Valenta, Ph.D.
vedoucí katedry doc. RNDr. Ing. Marcel Jiřina, Ph.D.
děkan
ZADÁNÍ BAKALÁŘSKÉ PRÁCE
Název: Adaptivní webové rozhraní pro zápis biologických dat Student: Petr Pilař
Vedoucí: Mgr. Filip Harabiš, Ph.D.
Studijní program: Informatika
Studijní obor: Webové a softwarové inženýrství Katedra: Katedra softwarového inženýrství Platnost zadání: Do konce letního semestru 2018/19
Pokyny pro vypracování
Moderní způsoby zápisu dat přinášejí řadu inovací, které ve svém výsledku mohou ušetřit velké množství času. V biologických odvětvích se často setkáváme se zažitými způsoby zápisu dat, které sice fungují, ale jsou často velmi neefektivní. Existuje řada databázových aplikací, které by měly svým uživatelům usnadnit zápis a editaci dat. Jedním se základních požadavků na tyto databáze je jejich univerzálnost, která je ale často činí neefektivními.
Cílem této bakalářské práce je vytvoření webové aplikace na míru požadavkům zapisovatele. Webová aplikace bude komunikovat s databází a bude mít administrátorské prostředí pro zakládání a úpravy modulů. Serverová část bude nabízet REST Api. Aplikace bude responzivní a uživatelsky přívětivá pro práci na mobilním zařízení a bude fungovat i při výpadku internetového spojení.
Seznam odborné literatury
Dodá vedoucí práce.
Bakalářská práce
Adaptivní webové rozhraní pro zápis biologických dat
Petr Pilař
Katedra softwarového inženýrství
Vedoucí práce: Mgr. Filip Harabiš, Ph.D.
Poděkování
V první řadě chci poděkovat vedoucímu Mgr. Filipu Harabišovi za rady a prak- tické postřehy při konzultacích a při tvorbě bakalářské práce. Následně děkuji
Prohlášení
Prohlašuji, že jsem předloženou práci vypracoval(a) samostatně a že jsem uvedl(a) veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací.
Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů.
V souladu s ust. § 46 odst. 6 tohoto zákona tímto uděluji nevýhradní oprávnění (licenci) k užití této mojí práce, a to včetně všech počítačových programů, jež jsou její součástí či přílohou, a veškeré jejich dokumentace (dále souhrnně jen
”Dílo“), a to všem osobám, které si přejí Dílo užít. Tyto osoby jsou oprávněny Dílo užít jakýmkoli způsobem, který nesnižuje hodnotu Díla, a za jakýmkoli účelem (včetně užití k výdělečným účelům). Toto oprávnění je časově, teri- toriálně i množstevně neomezené. Každá osoba, která využije výše uvedenou licenci, se však zavazuje udělit ke každému dílu, které vznikne (byť jen zčásti) na základě Díla, úpravou Díla, spojením Díla s jiným dílem, zařazením Díla do díla souborného či zpracováním Díla (včetně překladu), licenci alespoň ve výše uvedeném rozsahu a zároveň zpřístupnit zdrojový kód takového díla ale- spoň srovnatelným způsobem a ve srovnatelném rozsahu, jako je zpřístupněn zdrojový kód Díla.
České vysoké učení technické v Praze Fakulta informačních technologií
© 2018 Petr Pilař. Všechna práva vyhrazena.
Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními před- pisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných li- cencí a nad rámec oprávnění uvedených v Prohlášení na předchozí straně, je nezbytný souhlas autora.
Odkaz na tuto práci
Pilař, Petr. Adaptivní webové rozhraní pro zápis biologických dat. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2018.
Abstrakt
Náplní této práce je analyzovat problematiku zdlouhavého sběru biologických dat v terénu. Na základě analýzy procesů navrhnout webovou aplikaci, která bude responzivní a uživatelsky přívětivá. V části návrhu se práce věnuje nejen struktuře a vzhledu webových stránek, ale i problematice přihlašování, regis- trace a zabezpečení. Obsahuje popis průchodů webové aplikace dle určených scénářů. V práci je popsán postup tvorby webové aplikace a databáze, se kte- rou komunikuje přes objektově relační mapování. Práce analyzuje existující způsoby řešení a popisuje implementaci administrátorského prostředí, rozhraní REST API a offline módu pro případ výpadku internetového spojení.
Klíčová slova Responzivní web, Databáze, Uživatelská přívětivost, Biolo- gická data, Usnadnění zápisu, Administrátorké prostředí, REST, API, Offline mód.
Abstract
The objective of this thesis is to analyse the lengthy process of collecting bi- ological data in the field. Based on the findings design a responsive and user- friendly web application. The designing part is dedicated not only to structure
and appearance of the site, but also focuses on security issues such as regis- tration, or log in, allowing access only if specified scenarios are fulfilled. The thesis describes how the application and the database was created. How the application communicates with the database via object-relational mapping.
Furthermore, the thesis contains analysis of existing solutions and describes the implementation of administrative interface, the REST API interface and the offline mode in the event of Internet connection failure.
Keywords Responsive website, Database, User experience, Biological data, Facilitate inserting data, Admin environment, REST, API, Offline mode.
viii
Obsah
Úvod 1
1 Cíl práce 3
2 Analýza 5
2.1 Požadavky . . . 5
2.2 Stávající procesy . . . 7
2.3 Podobné aplikace . . . 9
2.4 Analýza databází a ORM . . . 10
2.5 Principy responzivní aplikace . . . 11
2.6 Principy přihlašování a zabezpečení . . . 13
2.7 Přístupnost a uživatelská přívětivost . . . 13
2.8 Praktiky REST API . . . 14
2.9 Praktiky tvorby offline módu . . . 16
3 Návrh 17 3.1 Nové procesy . . . 17
3.2 Architektura . . . 18
3.3 Role uživatelů . . . 19
3.4 Návrh struktury a grafiky . . . 20
3.5 Scénáře průchodu aplikací . . . 23
3.6 Zabezpečení . . . 27
3.7 Datový model . . . 27
3.8 Offline mód . . . 30
4 Implementace 33 4.1 Framework a bundly . . . 33
4.2 Databáze . . . 34
4.3 Objektově relační mapování . . . 35
4.4 Routování . . . 36
4.5 Controllery . . . 38
4.6 Formuláře a FormTypy . . . 45
4.7 Šablony a vzhled . . . 47
4.8 Javascript a offline mód . . . 50
4.9 Rozhraní REST . . . 52
Závěr 55
Literatura 57
A Seznam použitých zkratek 59
B Instalace a manuál 61
C Obsah přiloženého média 63
x
Seznam obrázků
2.1 Diagram vytvoření a výtisk archu pro pozorování . . . 8
2.2 Diagram pozorování jedinců . . . 9
2.3 Diagram přepisování vyplněných archů do tabulek či databází . . . 10
3.1 Diagram MVC . . . 18
3.2 Diagram ORM . . . 19
3.3 Diagram rolí . . . 20
3.4 Návrh horizontálního menu . . . 20
3.5 Návrh otevřeného verikálního menu . . . 21
3.6 Zobrazování webu na PC . . . 22
3.7 Zobrazování webu na tabletu . . . 22
3.8 Zobrazování webu na mobilním telefonu . . . 23
3.9 Databázový model . . . 28
3.10 Upozornění na zaznamenávání offline . . . 31
4.1 Generovaná adresářová struktura . . . 34
4.2 Vzhled formuláře pozorování druhu . . . 50
4.3 Snímek uložených cookies . . . 53
Seznam tabulek
2.1 HTTP metody a stavové kódy . . . 15
Úvod
V současnosti je sběr rozmanitých biologických dat v terénu velice časově ná- ročný. Tento proces je rozdělen na několik kroků. Nejdříve si musí pozorovatel připravit a vytisknout formuláře na daný pozorovaný druh. Následně, již v te- rénu, veškeré pozorované druhy a nálezy zapisuje do těchto formulářů. Pokud požaduje přesný čas či zeměpisnou polohu, musí si na to přinést odpovídající nástroje. Až po konci pozorování se veškerá získaná data převádí do určitých sdílených databází. Odborný pracovník tak musí všechna data projít nejméně dvakrát, tato práce mu může zabrat i několik hodin, a proto je potřeba se touto problematikou zabývat. Již existují dostupné mobilní a webové aplikace, které však požadují univerzálnost vkládaných dat. Právě to je činí nevhodné k všeobecnému použití, protože uživatel je limitován formátem dat využité databáze. Pokud chce uživatel zapisovat jen specifická data, tyto aplikace mu to znepříjemňují a musí se potýkat s nepřehlednými nevyužitými místy ve formuláři.
Tato práce bude sloužit především pro biology, kteří díky responzivní webové aplikaci ušetří velké množství času oproti stávajícímu procesu. Díky inovativnímu způsobu sběru dat a jejich uchování dojde k celkovému zefektiv- nění biologického výzkumu organismů. Vzhledem k univerzálnosti je aplikace vhodná nejen pro odborné pracovníky, ale pro všechny, kteří chtějí ukládat specifická data nejen z terénu.
Z důvodů, které vyplývají z předchozích odstavců, jsem se rozhodl zvolit si toto téma. S problematikou mě seznámil profesor Mgr. Filip Harabiš z České zemědělské univerzity v Praze, který se sběrem dat v terénu zabývá a potýká se i s problémy se sběrem spojenými. Následně mě oslovil se zadáním na tuto bakalářskou práci.
Bakalářská práce je rozdělena do tří částí. Postupně se zabývám analýzou problému, návrhem struktury aplikace a samozřejmě implementací již zmí- něné responzivní webové aplikace. Dle návaznosti jednotlivých kapitol pokra- čuje tato práce v následující struktuře. Nejdříve se věnuji analýze uživatelských
Úvod
požadavků, díky které jsem získal celkový přehled o problematice. V další části se věnuji tvorbě databáze a následně konverzi dat mezi databází a objektově orientovaným programovacím jazykem. Dále navrhuji responzivní a uživatel- sky přívětivé webové šablony. V následující části se zabývám problematikou metod přístupu ke zdrojům webové aplikace, konkrétně architekturou rozhraní Representational state transfer (REST) a Application Programming Interface (API). V předposlední části analyzuji existující řešení a popisuji implemen- taci speciálních formulářů, které budou sloužit k vytváření jiných formulářů.
Nechybí ani analýza principů webové aplikace v offline módu a popis imple- mentace.
2
Kapitola 1
Cíl práce
Cílem rešeršní části práce je analýza problému funkčních i nefunkčních uživa- telských požadavků na webovou aplikaci. Získání přehledu o existujících ře- šeních problémů zjištěných z analýzy. Porovnání různých databází pro výběr nejvhodnější databáze. Seznámení s principy tvorby responzivních webových aplikací pomocí technologií HyperText Markup Language (HTML), Cascading Style Sheets (CSS) a jazyka Javascript. Analýza problematiky tvorby a va- lidace webových formulářů. Popis problematiky přihlašování uživatelů a za- bezpečením aplikace. Studium konkrétních REST API praktik. Seznámení se základními principy pro práci v offline módu.
Cílem praktické části této bakalářské práce je vytvoření webové aplikace na míru, dle požadavků zapisovatele. Webová aplikace bude komunikovat s vy- branou databází a bude mít administrátorské prostředí pro zakládání a úpravy modulů. Serverová část bude nabízet rozhraní REST API pro přístup k da- tům v databázi. Aplikace bude responzivní a uživatelsky přívětivá pro práci na chytrých mobilních zařízeních. Protože zapisovatel nemusí mít vždy inter- netové připojení bude aplikace fungovat i při výpadku internetového spojení.
Kapitola 2
Analýza
Začátkem každého softwarového projektu by měla být důkladná analýza exis- tujících řešení a technologií. V následujících částech vás postupně seznámím s požadavky na aplikaci, ze kterých se musí vycházet. Následuje analýza stáva- jících procesů, kde přehledně ukáži, jak procesy vypadají. Poté představím již existující aplikace, které se snaží řešit tento problém. Také představím prin- cipy tvorby responzivní webové aplikace, přihlašování a zabezpečení. K závěru rešeršní části představím REST API a praktiky offline webu.
2.1 Požadavky
Analýza požadavků dokáže jednoduše určit všechny hlavní funkční a nefunkční požadavky na aplikaci. To slouží k vymezení hranic aplikace a k odhadu prac- nosti. Zatím, co funkční požadavky určují, jak a co má aplikace dělat, tak nefunkční nebo také obecné, určují omezení týkající se systému a podle nich se navrhuje architektura aplikace. Nejčastěji odpovídají na otázky výkonu, škálovatelnosti, spolehlivosti, dostupnosti a bezpečnosti. Pokud jsou požado- vány, je důležité poznamenat si kritéria měřitelným způsobem. Požadavky na aplikaci, kterou implementuji, jsou částečně dokumentované již v zadání, ně- které jsem si ale musel na konzultacích ujasnit. Následuje výpis požadavků a jejich popis.
Funkční požadavky:
FP-DA: Databáze živočichů
Aplikace bude pracovat se záznamy živočichů. Databáze bude udr- žovat informace o jednotlivých řádech živočichů, jejich druzích a sa- motných živočichů. Databáze bude navržená tak, aby podporovala ostatní požadavky a to uchovávání uživatelů, určování jejich práv, a další.
2. Analýza
FP-PR: Přihlašování uživatelů
Aplikace bude ve svém uživatelském prostředí umožňovat regis- traci nových uživatelů a následné přihlašování stávajících uživatelů.
Každý nový uživatel dostane základní balík práv.
FP-AD: Administrátorská práva
Někteří uživatelé budou administrátoři, tedy budou mít větší práva.
Stávající administrátor bude moci určit další administrátory nebo jim tyto výhradní práva sebrat.
FP-RV: Různé vlastnosti jedinců
Vlastnosti a hodnoty vlastností půjdou vytvářet na míru požadavků zapisovatele.
FP-MR: Vytváření/editace modulů řádu
Uživatelé s administrátorskými právy budou moci zakládat a upra- vovat moduly řádu.
FP-ML: Vytváření/editace modulů lokality
Uživatelé s administrátorskými právy budou moci zakládat a upra- vovat moduly lokality.
FP-PO: Možnost pozorovat jedince podle modulů
Samotné zapisování jedinců se bude lišit podle zvolených modulů a to právě jednoho modulu lokality a jednoho modulu řádu.
FP-NE: Neopakování vyplnění informací modulu lokality Při zapisování jedinců ve stejném pozorování bude stačit vyplnit informace o modulu lokality pouze jednou a ne při každém novém jedinci.
FP-OF: Offline mód
Vkládání jedince bude fungovat i při výpadku internetového připo- jení.
FP-SY: Synchronizace dat
Pokud po navrácení z offline módu existují nějací jedinci, kteří nejsou v databázi, aplikace zajistí, aby byli řádně uloženi do data- báze.
Nefunkční požadavky:
NP-WA: Webová aplikace
Aplikace bude implementována formou webu. Front-endová část bude nakódována v HTML a CSS a back-endová část bude napro- gramována v PHP. Nejsou kladeny požadavky na použití konkrét- ních knihoven či frameworků.
NP-OV: Ovládání
Webové rozhraní bude ovládáno standardně klávesnicí a myší, po- případě dotykem na dotykových mobilních zařízeních a tabletech.
6
2.2. Stávající procesy NP-OV: Responzivní chování
Aplikace bude responzivní, aby s ní mohli dobře pracovat i ti uži- vatelé, kteří jsou na mobilních zařízeních či tabletu.
NP-UX: Uživatelsky přívětivý vzhled
Aplikace nebude svým vzhledem kazit pohyb návštěvníka po stránce.
NP-AP: REST API
Aplikace bude nabízet toto rozhraní.
NP-RO: Rozšiřování databáze za běhu
Bude možné rozšiřovat databázi i v době kdy bude aktivní. Toto rozšiřování nijak nevyruší aktuálně přihlášené uživatele. Těm tedy nehrozí zhroucení systému a například ztracení aktuálních infor- mací. Registrace cílových uživatelů také neovlivní chod webové apli- kace.
Díky těmto požadavkům vím, jakou strategii při návrhu a implementaci apli- kace zvolit.
2.2 Stávající procesy
Modelování procesů zákazníka či zadavatele je nedílnou součástí analýzy. Díky zaznamenaným procesům se dá lépe pochopit činnost zadavatele. Aplikace se ruku v ruce snaží splnit potřeby ve formě požadavků a zároveň i zlepšit stá- vající procesy. Zlepšení samotných procesů se může týkat různých veličin, na- příklad času stráveného procesem, objemem dat, obtížností procesu, nalezení slabých nebo dokonce problémových míst procesu a jejich nahrazení. Proces je skupina aktivit uspořádaná podle časové osy a rolí v ní aktivních. Dá se chápat jako „černá krabička“, která má nějaké vstupy a odpovídající výstupy. Proble- matika bakalářské práce je zaměřená převážně na sběr dat z terénu. Stávající proces sběru dat můžu pro vyšší přehlednost rozdělit na tři samostatné pro- cesy. První proces je vytvoření a výtisk archu pro pozorování. Druhý proces je samotné pozorování jedinců a třetí proces je přepisování jedinců z vytiště- ných záznamových archů do tabulek či databáze. Nyní více rozepíšu tyto tři procesy.
Vytvoření a výtisk archu pro pozorování. Biolog si řekne, jaký řád chce pozorovat. Poté vymyslí, jaké všechny vlastnosti chce zapisovat u pozo- rovaných živočichů, a sepíše je na jedno místo. Aby biolog mohl následně vytisknout několik archů, zaznamenává si všechny informace do něja- kého textového či tabulkového editoru. V editoru musí vynaložit úsilí na to, aby vlastnosti byly čitelně usazené na stránce a byly seřazené podle jeho potřeby, aby nemusel při vyplňování přeskakovat mezi částmi archu a aby při zapisování do archu bylo dostatek místa na pozorované infor- mace. Jakmile je spokojený s archem v textovém editoru, vytiskne si ho,
2. Analýza
kolikrát chce. Samotné upravování archu v textovém editoru a následný tisk už může mít značný vliv na celkovou časovou náročnost celého pro- cesu.
Obrázek 2.1: Diagram vytvoření a výtisk archu pro pozorování
Pozorování jedinců. Jakmile biolog dorazí do lokality, kde chce pozorovat, začne ručně vypisovat informace o lokalitě. Arch může obsahovat i ko- lonky pro záznam data, času či jiných speciálních věcí. K většině z nich potřebuje biolog další předměty a pomůcky, které musí na pozorování brát s sebou. V tomto případě například stopky, hodinky či mobilní te- lefon. Jakmile vyplní arch s informacemi o lokalitě, čeká na pozorovaný druh. V okamžiku, kdy ho spatří, zapisuje do archu informace o pozo- rovaném jedinci. V nejhorším případě se může stát, že biologovi dojdou vytištěné archy nebo mu například dopíše pero. Jakmile je biolog se svým pozorováním spokojený, opouští lokalitu.
Přepisování vyplněných archů do tabulek či databází. V této fázi má biolog vyplněné archy a veškeré informace z nich musí přenést do da- tabáze. To znamená, že veškeré informace, které již jednou psal v ruce, musí nyní znovu přepsat do počítače, počítaje nejen názvy vlastností, 8
2.3. Podobné aplikace
Obrázek 2.2: Diagram pozorování jedinců
ale i samotná data. Tato aktivita je velice časově náročná a velice zne- příjemňuje celkový sběr dat. Kladem zůstává, že dvojitá kontrola dat může odhalit některé chyby a zároveň papírové archy slouží jako jakási záloha či důkaz pozorování.
Z bližšího popisu těchto tří procesů je jasné, že v návrhové části bude větší prostor pro návrh optimálnějších postupů a aktivit.
2.3 Podobné aplikace
Přestože se stávající proces sběru biologických dat nezdá být dostatečně mo- dernizovaný, existuje pouze málo aktivních systémů nebo aplikací, které pra- cují s touto problematikou. Mezi nejvíce používané patří mobilní aplikace BioLog dostupná na adresehttps://play.google.com/store/apps/details?id=
cz.nature.biolog. Aplikace je dobře optimalizovaná, je zdarma a nabízí roz- sáhlou databázi živočichů. Velkou výhodou je přímá spolupráce s agenturou ochrany přírody a krajiny České republiky. Naproti tomu její největší nevý- hoda je neschopnost umožnit uživateli pozorovat živočichy pouze podle zvole-
2. Analýza
Obrázek 2.3: Diagram přepisování vyplněných archů do tabulek či databází
ných vlastností. Každý druh má předem zvolené vlastnosti/atributy, které se zadávají ve formuláři. Ačkoliv tyto vlastnosti nejsou povinné, může jich být ve formuláři mnoho a uživatel pak musí vyhledávat pouze ty, ke kterým chce na- psat pozorovanou informaci. Další nevýhodou je fakt, že mobilní aplikace exis- tuje pouze na chytré mobilní telefony s operačním systémem Android. Tedy ji uživatelé ostatních platforem nemohou používat. Další aplikací pro pozorování živočichu je Collins Bird Guide dostupná zhttps://play.google.com/store/
apps/details?id=com.natureguides.birdguide. Aplikace se však zaměřuje pouze na sledování ptactva a nelze tedy použít ke všeobecnému pozorování.
Aplikace slouží hlavně jako encyklopedie do kapsy s možností pozorování.
Aplikace stojí okolo 400 Kč, což se pro většinu amatérských pozorovatelů ptactva může zdát jako velká počáteční investice. Nabízí však krásné vlastní ilustrace většiny druhů.
2.4 Analýza databází a ORM
Podle požadavků zmíněných dříve, se požaduje implementace databáze a ko- munikace webové aplikace s databází. Musíme tedy vytvořit danou databázi, ale nastává otázka, jakou a proč. V dnešní době existuje celá řada databází jako systémů, které umožňují strukturovaně ukládat data. Databáze se rozli- šují podle takzvaného databázového modelu. Mezi nejčastější logické databá- zové modely patří relační, objektový, hierarchický, síťový a XML model. Dle průzkumu společnosti Stack Overflow v roce 2018, kterého se zúčastnilo více než 100 000 vývojářů, je databáze MySQL nejvíce používaná profesionálními vývojáři [1]. Díky tomuto údaji a faktu, že s databází typu MySQL mám nej- více zkušeností, jsem se rozhodl použít ji i v této práci. Jedná se o relační databázi, která je založená na tabulkách a relacích mezi nimi. V tabulkách jsou záznamy ve formě řádků a sloupce a tabulky jsou jednotlivé atributy záznamů. Relační model je pro tento případ ideální. Pro srovnání s dalšími 10
2.5. Principy responzivní aplikace modely. Na rozdíl od XML modelu neukládá velké množství opakujících se hodnot a umožňuje lepší i obecnější relace. Síťový model je orientovaný graf, který spojuje přímo data nikoliv tabulky, a proto není vhodný. Hierarchický model by na první pohled mohl působit, že je pro uchovávání řádů živoči- chů, jejich druhů a samotných jedinců ten pravý. Nenechme se ovšem zmást, databáze této webové aplikace nebude uchovávat jen tato data, nýbrž podle požadavků i všechna ostatní data, pro které již hierarchické uspořádání nedává dobrý smysl.
Po volbě databáze přichází na řadu propojení databáze a programu. To zajistí takzvané objektově relační mapování (ORM). Stejně jako u frameworků, tak i zde máme na výběr z několika variant Propel, Doctrine, Outlet a další.
Dle výsledků porovnání je nejlepší ORM framework Doctrine [2]. Doctrine je kompatibilní s PHP 5.2.3 a vyšší. Databáze MySQL patří do jeho široké nabídky podporovaných databázových systémů.
Databázový systém je vybrán, teď musím zjistit, jaká data do něj budu ukládat. Nyní uvedu, pro jaké entity bude potřeba mít tabulky v databázi.
Samotný návrh tabulek a relace mezi nimi budou v kapitole návrhu. Podle požadavků je jisté, že databáze bude obsahovat řády živočichů, jejich druhy a samotné pozorované jedince. Taktéž budu potřebovat nějaké pozorování a to se podle požadavků skládá z modulů řádu a lokality. A to jsou další entity do databáze. Moduly budou tvořené vlastnostmi a ty je také potřeba zaznamenat.
To všem ovládá uživatel, u kterého si potřebuji pamatovat základní informace a role pro případná administrátorská práva.
2.5 Principy responzivní aplikace
Pokud je aplikace responzivní, znamená to, že se chová a vypadá dobře na pře- vážné většině či dokonce všech zařízeních. Mezi tyto zařízení patří například chytrý mobilní telefon s menším displejem, s větším displejem, malý tablet, velký tablet, notebook či stolní počítač s normální velkou obrazovou. Rozpětí rozlišení, velikostí a poměrů stran displejů a obrazovek je tak opravdu velké a responzivní aplikace si s tím musí umět poradit. U webů se tohoto cíle dá dosáhnout pomocí dobře napsané struktury v HTML a s podporou grafiky díky CSS. Je velice důležité, aby struktura určité webové stránky byla oddě- lená od jejího vzhledu. Například pokud mám číslovaný seznam, bude to stále tentýž číslovaný seznam, i když si ho zobrazím na počítači či mobilním tele- fonu. Teprve již zmíněné CSS, pro tento příklad, může seznam upravit, změnit odsazení nebo jinak ovlivnit jeho grafickou stránku. Existují dva přístupy k vý- voji responzivního webu. První Desktop first a druhý Mobile first [3]. Jak již z názvu vyplývá, odlišují se tím, na jaké zařízení se web vytváří jako první.
U Desktop first se webová stránka vytváří pro počítač, tedy velké obrazovky.
Tato metoda začíná úplně stejně jako normální výroba webu. Jakmile je struk- tura webu a grafika hotová, autor se začne zamýšlet, jak nastavit grafiku, aby
2. Analýza
se dobře zobrazila i na menších zařízeních. K tomu slouží, krom jiného me- dia query a breakpointy. Media query jsou speciální pravidla v CSS, která se uplatní, pokud je splněná nebo naopak není splněná nějaká podmínka. V pří- padě responzivní aplikace se používají k uplatnění pravidel ovlivňující vzhled stránky, nejčastěji podle šířky obrazovky. Ukázka kódu 1 zajistí, že jakmile je šířka stránky menší než 600 px, aplikuje se pravidlo, které nastaví barvu pozadí stránky na světle modrou [4].
@media only screen and (max-width: 600px) { body {
background-color: lightblue;
} }
Výpis kódu 1: Desktop first
Media query se perfektně hodí v případě, když chceme stránku vytisk- nout. Stačí nastavit pravidlo změny stylu, které se uplatní, pokud se stránka pošle do tiskárny. Pro barevné stránky nebo stránky s obrázky je to ide- ální. Tímto se dostávám k breakpointům. Breakpoint je spojení normálních CSS tříd a zmíněného media query. CSS umí přistupovat k názvům tříd za pomoci regulárních výrazů a pak může media query upravit více tříd najed- nou. Můžeme s ním tedy určit, jaké elementy podle CSS tříd se mají změnit a jak. Nyní k druhému přístupu vývoje responzivního webu mobile first. Při postupu mobile first nejdříve autor píše webovou stránku tak, aby vypadala dobře na mobilním zařízení, poté přidává pravidla pro změnu grafiky na vět- ších a větších obrazovkách. Příklad kódu 2 je mobile first, kde je jasně vidět rozdíl v max-width a min-width, oproti ukázce desktop first kódu. Pro tvorbu mé webové aplikace si zvolím mobile first postup. Nejen proto, že aplikace má podle zadání dobře fungovat na mobilních zařízeních, ale i kvůli čitelnosti CSS stylů. Pro mobile first se přidávají nová pravidla, pokud je stránka větší, ale žádná pravidla se nemusejí přepisovat či mazat. Tomu tak bohužel je u více přirozeného desktop first.
@media only screen and (min-width: 600px) { body {
background-color: red;
} }
Výpis kódu 2: Mobile first
12
2.6. Principy přihlašování a zabezpečení
2.6 Principy přihlašování a zabezpečení
Při práci s uživateli se ve webové aplikaci potýkáme s procesy autentizace a autorizace. Autentizace je proces, jenž ověří uživatele, který přistupuje do aplikace. Autentizace tedy probíhá vždy při přihlašování a uživatel se proka- zuje nějakou informací jako je heslo, PIN, otisk prstu nebo sken sítnice oka.
Každá z těchto metod má své klady a zápory. Nejčastěji se používá dvojice uživatelské jméno a heslo. Autentizace přes tuto dvojici nevyžaduje žádný spe- ciální hardware a dobře se implementuje. Uživatelské jméno i heslo je typicky textový řetězec. Příklad primitivního přihlášení spočívá v tom, že uživatel ode- šle serveru svoje uživatelské jméno a heslo. Server podle uživatelského jména najde v databázi záznam uživatele a zkontroluje, zda se heslo, co mu odeslal, shoduje s heslem v databázi. Pokud se hesla shodují, tak je uživatel puštěn do aplikace a pokud ne, tak nikoliv. Příklad byl inspirován článkem o identifikaci uživatelů [5]. Tento způsob je velice naivní, protože kdokoli, ať už se z jaké- hokoli důvodu dostane do databáze, se může podívat na hesla všech uživatelů a pak je zneužít. Ze studie o uživatelských heslech víme, že šokujících 43 % uži- vatelů používá stejné heslo na různých webových stránkách napříč internetem [6]. Proto uvedený příklad špatného zabezpečení je opravdu velkou hrozbou pro uživatele. Zásadou je nikdy neuchovávat uživatelské heslo v plaintextu.
Příklad by tedy byl o poznání bezpečnější, pokud by vypadal následovně.
Uživatel odešle serveru svoje uživatelské jméno a heslo. Hned jakmile server obdrží tyto informace, převede heslo pomocí hashovací funkce na hash. Tato operace je jednosměrná a pro stejný vstup má vždy stejný výstup, tedy získat heslo s jeho hashe je prakticky nemožné. To znamená, že do databáze se při registraci uložil pouze hash z hesla a při přihlašování se porovnává s hasham hesla z přihlašovacího formuláře.
Všechny informace poskytované při autentizaci je možné nějakým způso- bem zneužít. Pokud uživatel webových stránek zadá špatné heslo, vrátí se mu zpráva o tom, že se hesla neshodují. V tom je ale opět háček. Přesto se může zdát, že zpráva o neshodujících se heslech nelze zneužít. Z pohledu útočníka jsme právě zjistili důležitou informaci, že zadané uživatelské jméno v data- bázi je [7]. Proto se doporučuje při neúspěšném přihlášení, dát vědět uživateli pouze to, že se přihlášení nezadařilo. Dalším způsobem rozšíření zabezpečení je vícefázové ověření. To může proběhnou přes různé komunikační kanály. Nej- častěji přes email, aplikaci nebo SMS. To můžeme ale pouze za předpokladu, pokud známe validní uživatelský email či číslo telefonu.
2.7 Přístupnost a uživatelská přívětivost
Webová stránka je přístupná, pokud se dobře používá, všem návštěvníkům bez ohledu na jejich schopnosti a postižení. Mezi návštěvníky samozřejmě patří lidi, ale nejen to. Na webové stránky občas přistupují i roboti vyhledávačů,
2. Analýza
kteří si stránku projdou a zpracují. V následujícím textu se budu věnovat lidské části návštěvníků. Přesto, že je každý člověk jiný a jinak vnímá své okolí, webová stránka musí být přizpůsobená na to, aby se všem prezentovala stejně. Procházení webové stránky rozsahu této práce je ze 100 % zaměřeno na zrak. Bohužel zrakové vady patří k nejčastějším a je potřeba se touto proble- matikou zabývat. Mezi lehčí postižení zraku patří slabozrakost, krátkozrakost, dalekozrakost a barvoslepost několika typů. Návštěvník webů však může trpět pouze krátkodobým snížením kvality zraku, například když ráno vstane, nebo naopak podvečer. Mezi dobré zvyky přístupnosti patří následující. V každé části webové stránky se musí uživatel orientovat, vědět kde a proč je. Zároveň by měl být schopen dostat se na úvodní stránky jedním kliknutím. Titulky, nadpisy a odkazy by měly dávat jasně najevo, jaký text bude následovat, popřípadě kam nás odkaz přenese [8].
Samotná správná struktura stránky je esenciální. Nikdy se nemá zmenšovat text a velikost textu by se nikdy neměla udávat v jednotkách, které závisí na velikosti či rozlišení obrazovky, například v pixelech. Tento problém se dá jasně pozorovat, pokud zobrazíme statický text na mobilu nebo na 4K obrazovce. Na takto velké obrazovce bude velikost jednoho pixelu tak malá, že text nepůjde vůbec přečíst. Barevný vzhled stránky přináší nové problémy. Jedním z nich je kontrast barvy textu s barvou pozadí. Je zcela nezbytné, aby text byl dobře vidět na zvoleném pozadí, tedy kontrast musí být co největší. V úvahu připadá mezi weby nejvíce rozšířený černý text na bílém pozadí a obráceně. Tento vzhled mě zaujal a budu z něho později vycházet. Návštěvníci stránek jsou zvyklí na standardní zobrazování odkazů pomocí modrého textu s podtržením.
Tento vzhled je trnem v oku většiny grafiků. Pokud jsou na webové stránce obrázky, které jsou důležité pro kontext stránky, je nutné uvést doplňující text v případě, že se obrázek nepovede zobrazit. Nejdůležitější je dodržovat stejné zásady napříč celou webovou aplikací.
Důležité je se vyvarovat prvkům stránky, které připomínají reklamu, ale reklamou nejsou. Termín banner blindness není obecně známý, ale setkáváme se s problematikou, co popisuje, dnes a denně. Každý, kdo prohlíží webové stránky na internetu, zná internetové reklamy. Většinou svým velmi výrazným vzhledem nezapadají do stylu stránky. Lidské vnímání se přizpůsobilo a začalo ignorovat takto výrazné plochy. Pokud je tedy součástí stránky prvek, který vypadá jako reklama, může se snadno stát, že ho návštěvník bude prostě ignorovat a nedozví se tak informaci, kterou hledal.
2.8 Praktiky REST API
Z uživatelských požadavků je jasné, že se vyžaduje webová aplikace. Taková aplikace je založená na komunikaci klient–server. Toto rozdělení je zásadní a každé má jiné části, které se dají vyvíjet nezávisle. Komunikace spočívá v tom, že klient posílá požadavky na server, server požadavky zpracuje a po- 14
2.8. Praktiky REST API Tabulka 2.1: HTTP metody a stavové kódy
metoda funkce kolekce entita
POST vytvoření 201 (Created) 404 (Not Found)
GET čtení 200 (OK) 200 (OK) / 404 (Not Found)
PUT editace 405 (Not Allowed) 200 (OK) / 404 (Not Found) DELETE smazání 405 (Not Allowed) 200 (OK) / 404 (Not Found)
kud to práva klienta povolují, odpoví klientovi. Veškerá takzvaná business logika je na serverové části. Webová aplikace se skládá ze statických a dyna- mických stránek [9]. Při vyžádání statické stránky prohlížečem vrátí server vždy tu samou stránku. Naopak u dynamické stránky server nejdříve určí, co prohlížeč požaduje a před vrácením stánky ji upraví. Proto ta samá dyna- mická stránka může obsahovat jiná data. Při normálním prohlížení webových stránek je klient ve většině případů nějaký webový prohlížeč (Google Chrome, Internet Explorer, Mozila Firefox, …), server tedy odpovídá tomuto prohlížeči.
Server může umožnit komunikaci i s jinými programy či aplikacemi a právě k tomu slouží API. API neboli Application Programming Interface je veřejné rozhraní, které umožňuje přístup k datům a funkcím serveru všem žádaným konzumentům.
REST je styl architektury, který se rozšířeně používá pro API. „REST toto API definuje za vás. Je to rozhraní pro distribuované prostředí orientované na data, nikoli na volání procedur jako např. RPC (XML-RPC) či SOAP.“ [10].
V praxi REST komunikuje se serverem na HTTP protokolu. Požadavek na server se distribuuje podle zvoleného zdroje. Tento zdroj podle nadefinova- ného chování vrátí odpovídající data ve vyžadovaném formátu. Existuje ně- kolik typů dotazování, ty určují http metody. Nejpoužívanější http metody jsou GET, POST, PUT a DELETE. Metoda GET slouží ke čtení, tedy server načte data z databáze a vrátí je. To je klasický příklad prohlížení webových stránek. Metoda POST slouží k vytvoření nové kolekce záznamů. Tělo poža- davku s metodou POST musí obsahovat data, podle kterých server vytvoří a běžně i uloží do databáze nový záznam. Metoda PUT je určená pro vložení záznamu do kolekce, úpravu již existujícího záznamu nebo jeho nahrazení, tělo požadavku také musí obsahovat nová či pozměněná data záznamu. Tím se dostávám k metodě DELETE, která je navržená pro odstranění záznamu z rodičovského záznamu. Jakmile je záznam odstraněn, nelze ho již nalézt na stejném zdroji například metodou GET, jako to bylo před odstraněním [11].
Na tyto požadavky server odpovídá krom požadovaných dat i stavovým kó- dem. Následuje tabulka 2.1 možných návratových stavových kódů, použitá ze zdroje [12].
Nutno zmínit, že existují i další metody, avšak zmíněné metody zajišťují kompletní operace CRUD pro práci s databázovými daty a to je ideální pro implementační část práce.
2. Analýza
2.9 Praktiky tvorby offline módu
Webové aplikace z principu komunikují se serverem. Zatím co prohlížeč na straně uživatele nabízí pouze pohled na webové stránky a interakci s nimi, veškerá řídící logika se provádí na serveru. Je to logické, protože server fun- guje jako jeden logický bod a uživatelů může být více, dokonce i na více platformách. Pokud chci, aby aplikace fungovala i při výpadku internetového připojení, musím přesunout řídící logiku ze serveru na uživatele. To by poté ale server nemohl rozhodovat za více uživatelů najednou. Toto řešení má na- víc i bezpečnostní rizika, protože citlivé údaje řídící logiky jsou nyní uloženy u všech uživatelů. Dalším způsobem může být, v případě omezení spojení, dočasné ukládání informací na straně uživatele a řídící logika zůstane na ser- veru. Po navázání spojení vznikne potřeba správného začlenění offline dat do databáze, ke které mezi tím mohli přistupovat jiní uživatelé. Pro ukládání dat připadají v úvahu dva prostory [13]. První prostor jsou cookies. Cookies jsou textové soubory, ke kterým má přístup uživatel i server a přenášejí se v kaž- dém požadavku i odpovědi. Druhý prostor je web storage, která umožňuje ukládat větší množství dat než cookies, avšak pouze na straně uživatele. Práce s cookies se nabízí, protože částečně již řeší odeslání offline napozorovaných dat na server ke zpracování.
16
Kapitola 3
Návrh
Po důkladné analýze problematiky technologií vyplívajících ze zadání práce, následuje část návrhu. Návrh je nedílnou součástí každého softwarového pro- jektu. V této kapitole ukáži, jakým způsobem se dají vylepšit zmíněné procesy sběru dat v terénu, ideální způsob nasazení aplikace. Rozeberu případy užití aplikace s pohledem na role uživatelů. Také se zde věnuji datovému modelu, celkovému zabezpečení a návrhu řešení offline módu.
3.1 Nové procesy
V analytické části jsem uvedl tři hlavní procesy, se kterými se uživatelé apli- kace potýkají. Pro zopakování, prvním procesem je vytvoření a výtisk archu pro pozorování. Druhým procesem je samotné pozorování jedinců a třetím procesem je přepisování jedinců z vytištěných záznamových archů do tabu- lek či databáze. Nyní popíši, jakým způsobem hodlám tyto procesy vylepšit a zbavit je stávajících slabých míst.
Z prvního procesu je jasné, že pokud bude biolog používat tuto webovou aplikaci, nepotřebuje ke své práci znalost externího textového editoru a také nepotřebuje tisknout archy, což jsou hlavní aktivity, které navyšují celkovou pracnost a časovou složitost. Naopak aktivita vymyšlení vlastností a typů vlastností musí být zachována, aby bylo dosaženo maximální možné specifity.
Existuje však i možnost, že se biolog inspiruje archem jiného biologa a ten již nemusí arch pracně vytvářet, nicméně aktivita tisku zůstane. Tato možnost sdílení vlastností či modulů musí být zachována.
Druhý proces probíhá již v lokalitě pozorování. Tento proces požaduje, aby biolog měl více pomůcek, přičemž jejich používání může znepříjemňovat jeho práci. Vylepšení tedy spočívá v tom, že webová aplikace bude některé položky moci vyplnit za něj a tím mu usnadní práci. Samotné pozorování probíhá vyplňováním vlastností modulu lokality a následně, dokud biolog požaduje, vyplňováním vlastností modulu druhu. Tato část procesu tedy nejde obejít.
3. Návrh
To se ale netýká posledního třetího procesu.
Třetí proces obsahuje aktivity, které nyní díky webové aplikaci můžeme úplně vypustit. Dojde tak k drastickému vylepšení časové náročnosti. Jelikož je webová aplikace navržená tak, aby ukládala data přímo do databáze, od- padá potřeba vytváření tabulky pro záznamy vlastností z pozorovacích archů i samotný přepis záznamů. V praxi to může být úleva v řádu několika hodin.
3.2 Architektura
Pro webovou aplikaci založenou na komunikaci klient-server je žádoucí, aby oddělila datový model a řídící logiku. o to se postará softwarová architektura model view controller MVC, která rozděluje aplikaci dokonce do tří částí, které spolu komunikují, ale navzájem do sebe nezasahují. Tyto části jsou datový model, uživatelské rozhraní a řídící logika. Části jsou navržené tak, aby se v případě nutnosti daly vyměnit a nemusela se měnit celá aplikace. To je užitečná vlastnost při potřebě změny databáze nebo uživatelského rozhraní.
Následuje obrázek 3.1 architektury MVC.
Obrázek 3.1: Diagram MVC
Pokud klient pošle požadavek na server, může aplikace zapojit všechny tři části, než vrátí odpověď. Požadavek putuje přes internet, než se dostane na server. Zde ho zpracuje controller neboli řídící logika. Pokud je potřeba, tak controller komunikuje s datovým modelem a získá potřebná data. Cont- roller může data dodatečně zpracovat a zavolá view, tedy uživatelské rozhraní, 18
3.3. Role uživatelů které vygeneruje kód, který se klientovi zobrazí. Výměna uživatelského roz- hraní přichází v úvahu s myšlenkou zavedení webové aplikace do více systémů.
Odpověď následně doputuje ke klientovi a proces se může opakovat. Datový model slouží převážně k uchovávání dat, tím pádem v něm musí být zahrnutá databáze. Mezi databází v datovém modelu a řídící logikou je ještě jeden dů- ležitý prvek. Jedná se o ORM, neboli objektově relační mapování. Z názvu je patrné, že se jedná o mapování, tedy konverzi dat mezi relační databází, která je naplněna tabulkami, záznamy v nich a relacemi mezi nimi, na objekty se kterými pracuje řídící logika.
Obrázek 3.2: Diagram ORM
Nebýt ORM, řídící logika by se musela starat o samotné ukládání a per- zistenci dat v databázi a to by značně ztížilo celkovou pracnost a přehlednost.
ORM také zajištuje synchronizaci těchto dat a to oběma směry. Díky ORM odpadá v řídící logice nutnost psát SQL dotazy. Místo SQL dotazů, tedy do- tazu nad samotnou SQL databází, pracuje řídící logika se třídami/objekty a kolekcemi tříd / kolekcemi objektů.
3.3 Role uživatelů
Z funkčních požadavků na webovou aplikaci vyplývá potřeba navrhnout hie- rarchii uživatelských rolí. To znamená, že návštěvníci webových stránek nebu- dou mít stejná práva. V aplikaci se budou vyskytovat úseky, ke kterým bude mít přístup jenom někdo. Nyní představím uživatelské role, dle počtu práv sestupně. Nejvyšší oprávnění bude mít role administrátorská. Administrátor bude moci provádět všechny akce, které bude webová aplikace podporovat.
Další rolí bude už normální uživatel, avšak takový, který bude přihlášený.
Ten bude moci stále vykonávat většinu akcí. Pouze ty ryze administrátorské akce mu budou zamítnuty. Návštěvník s nejméně právy je nepřihlášený uživa- tel nebo také anonymní uživatel. Takový uživatel má velice omezený přístup do aplikace. Mezi akce, které může provádět spadá převážně prohlížení části databáze s živočichy. Administrátorská práva budou moci být udělena a ode-
3. Návrh
brána administrátorem, tedy administrátor musí být velice rozvážný komu taková práva udělí. Následuje diagram 3.3 rolí, kde je počet práv dané role vyjádřev velikostí role.
Obrázek 3.3: Diagram rolí
3.4 Návrh struktury a grafiky
Pro jednotlivé stránky aplikace volím, kvůli přehlednosti a jednoduchosti, stej- nou strukturu. Udělám tedy jakousi kostru, ve které se bude podle obsahu jednotlivých stránek měnit obsahová část, ale zbytek zůstane stejný. Stej- ným způsobem jsem pojal i samotný vzhled. Zpět ke struktuře. Je jisté, že webová aplikace potřebuje domovskou stránku, dále podle požadavků i oblast pro přihlašování a registraci. Určitě musí nabízet pohled na prvky databáze, tedy řády, druhy a jedince. Dalším požadavkem bylo vytváření modulů lo- kality a modulů řádu a s tím jsou spojené i vlastnosti. Bývá zvykem uvést i stránku s kontakty, ačkoli na ní budou jen informace o mně samotném. Na- konec určitě nesmí chybět oblast pro správu pozorování a samotné pozorování.
Všechny tyto věci jsem rozdělil na skupiny a vytvořil dva hlavní oddíly. První oddíl s hlavní stránkou, přihlašováním, odhlašováním, registrací a kontakty.
Následuje obrázek 3.4 návrhu horní části.
Obrázek 3.4: Návrh horizontálního menu 20
3.4. Návrh struktury a grafiky Ve druhém oddílu se nachází položky z výpisu. První oddíl jsem navrhl jako horizontální menu v horní části stránky. Položky z druhého oddílu jsem rozdělil do logických podskupin a umístil je do vertikálního menu, podél levé strany stránky. Tyto logické podskupiny jsou: databáze, pozorování a mo- duly. Po zamyšlení přidávám ještě odkaz export, který nyní vede na prázdnou stránku, avšak do budoucna může být užitečný. Vertikální menu pro druhý oddíl, zabírá nezanedbatelnou část stránky, a proto dojde při zobrazování strá- nek na menších zařízeních k jeho skrytí. Uživatel se však nemusí bát, že by nyní položky menu nenašel. V horizontálním menu prvního oddílu, ale v pravé části se objeví velká ikona menu. Po kliknutí na tuto ikonu vyjede z levé části obrazovky ono skryté menu. Následuje obrázek otevřeného 3.5 vertikálního menu.
Obrázek 3.5: Návrh otevřeného verikálního menu
V dolní části obrazovky se nachází zápatí. V horizontálním menu se nachází položka kontakty, která je na malých zařízeních kvůli úspoře místa skryta. Na pravé straně stránky se vyskytují dvě plovoucí plochy. Jejich použití slouží k informovanosti návštěvníka o použitých technologiích. Tyto plochy ničemu nepřekážejí a při změně velikosti stránky, se dynamicky přizpůsobují obsahu.
Na nejmenších zařízeních se nachází mezi hlavním obsahem stránky a zápa- tím v plné šířce. Ve všech částech, kde se nahlíží na data databáze, jsem zvolil podobný způsob zobrazování. Jedná se o tabulku záznamů. Tabulka je umís- těna v responzivní sekci stránky, pokud tedy dojde k velkému zmenšení, objeví se posuvná lišta a uživatel na mobilním zařízení může prohlížet celý obsah.
Obrázky návrhu stránky na velké obrazovce 3.6, na tabletu 3.7 a na mobilu
3. Návrh
3.8.
Obrázek 3.6: Zobrazování webu na PC
Obrázek 3.7: Zobrazování webu na tabletu
Zvolil jsem jednoduchý černobílý vzhled, kde se vyjímají tlačítka formu- lářů, ikony odkazů a obrázky řádů, druhů a jedinců. Ačkoliv pozadí není čistě bílé, neporušuje s textem obsahu pravidlo vysokého kontrastu. Všechny for- muláře mají stejný vzhled, opět kvůli soudržnosti.
22
3.5. Scénáře průchodu aplikací
Obrázek 3.8: Zobrazování webu na mobilním telefonu
3.5 Scénáře průchodu aplikací
Protože webová aplikace z velké části změnila procesy spojené se zaznamená- váním dat, je nutné si uvědomit, jakým způsobem se bude uživatel po stránce pohybovat. Popis scénářů a případů užití a jejich modelování spadá do ana- lytické části práce, nicméně zde v části o návrhu se chci věnovat již novým scénářům týkajících se webové aplikace. Nyní proberu hlavní scénáře průchodů aplikací, podle rolí uživatelů.
3.5.1 Nepřihlášený (anonymní) uživatel
• Navštívení úvodní stránky, následná registrace a přihlášení.
1. Uživatel zadá do adresního řádku svého prohlížeče adresu webové aplikace a stiskne tlačítko „Enter“.
3. Návrh
2. Při prvním navštívení webu se uživatel vyskytne na domovské stránce.
V horní části je menu, zde klikne na tlačítko „Registrovat“.
3. Tím se uživatel přesunul na stránku s registračním formulářem. Zde postupně vyplní všechny údaje a zaškrtne, že rozumí podmínkám.
Poté klikne na tlačítko „Uložit“ na konci formuláře.
4. Pokud vše zadal správně, webová aplikace ho přesměruje na hlavní stránku. Pokud zadal něco špatně, opakuje 3. krok.
5. Nyní po registraci je možné se přihlásit. Uživatel klikne v horním menu na kolonku přihlásit.
6. Tím se dostane na stránku přihlašovacího formuláře. Zde vyplní uživatelské jméno a heslo a klikne na tlačítko „Přihlásit“.
7. Pokud zadal své údaje dobře, aplikace ho přesměrovala na domov- skou stránku a je přihlášený. Pokud zadal své údaje špatně a nepo- vedlo se mu přihlásit, může to zkoušet znovu dokud nedojde k úspě- chu.
• Nalezení seznamu modulů.
1. Uživatel přijde na hlavní stránku webu.
2. Pokud uživatel prohlíží webovou stránky na dostatečně velké ob- razovce, klikne vlevo ve vertikálním menu na odkaz „Moduly“. Po- kud je uživatel na zařízení s menší obrazovkou, musí si toto menu nejdříve zobrazit kliknutím na ikonu „menu“, které se nachází v pra- vém horním rohu stránky a poté pokračuje stejně.
3. V obou případech ho odkaz převede na stránku s nadpisem „Mo- duly“. Zde si vybere, jaké moduly chce prohlížet a klikne na odpo- vídající odkaz.
4. Tím se ocitne na stránce, která obsahuje seznam všech vybraných modulů. Ze seznamu může vyčíst maximálně dvě použité vlastnosti a obdobně dvě použitá pozorování, které využil tento modul.
Stejným způsobem, jako uživatel navštívil stránku se seznamem všech modulů, může procházet i všechny záznamy řádů, druhů a samotných živočichů. U těchto entit si může nepřihlášený uživatel zobrazit i detaily.
Také může procházet všechny vytvořené pozorování a vlastnosti, ovšem už si nemůže zobrazit jejich detail.
Přihlášený uživatel má již o poznání větší přístup do webové aplikace. Jeho nejzajímavějším průchodem je bezesporu celkový průběh pozorování jedinců a vytváření nových vlastností. Mimo jiné může editovat i mazat jedince v da- tabázi, zobrazovat detailní popis modulů řádu i modulů lokality a aktivovat či deaktivovat nějaké pozorování pro svůj profil podle libosti.
24
3.5. Scénáře průchodu aplikací 3.5.2 Přihlášený normální uživatel
• Aktivování a následné deaktivování vybraného pozorování.
1. Uživatel ve vertikálním menu klikne na položku „pozorování“ a pře- sune se na stránku, která mu zobrazí seznam všech pozorování.
2. Zde si může vybrat pozorování, kterým chce pozorovat živočichy, orientuje se podle řádu, který chce pozorovat. V seznamu i v detailu může nahlížet i do detailů modulů obojího druhu. Uživatel tedy v pravé části stránky klikne na odkaz „Detail“, který ho převede na detail pozorování.
3. Uživatel se rozhodl, že toto pozorování je to pravé a chce ho ak- tivovat. Klikne tedy v pravé části stránky na odkaz „Aktivovat“, který zajistí aktivaci.
4. Poté aplikace přesměruje uživatele na jeho profil, kde se může ujis- tit, že si aktivoval správné pozorování.
• Celkový průběh pozorování jedinců (online).
1. Uživatel je přihlášen a má aktivované pozorování. Nyní chce pozoro- vat živočichy a zapisovat jejich informace podle modulů v aktivním pozorování.
2. Ve vertikálním menu klikne na položku „Pozoruj“, která ho přemístí na první část pozorování.
3. V první části pozorování se jedná o vyplnění formuláře podle vlast- ností modulu lokality. Vyplní tedy všechny položky formuláře a klikne na tlačítko „Pokračovat“.
4. Nyní se uživatel nachází v druhé části pozorování, kde se nachází formulář s vlastnostmi, podle zvoleného modulu řádu. Uživatel za- čne tento formulář vyplňovat. Každý formulář modulu řádu začíná výběrem druhu a končí časem nalezení. Jakmile uživatel zpozoruje nějaký druh a zjistí o jaký se jedná, vybere ho. V tu chvíli se auto- maticky uloží čas od začátku pozorování.
5. Uživatel klikne na tlačítko na konci formuláře, kterým je „Uložit je- dince“. Jedinec, spolu se všemi hodnotami pozorovaných vlastností, se uloží. Stránka se znovu načte a uživatel může opakovat 4. a 5.
bod, dokud chce pozorovat jedince.
• Vytváření nových vlastností
1. Uživatel projde procesem přihlášení nebo registrací a přihlášením a nachází se na hlavní stránce.
2. Ve vertikálním menu zvolí položku „Moduly“ a přesune se do sekce s moduly a vlastnostmi.
3. Návrh
3. Klikne na odkaz „Vlastnosti“, který ho převede na stránku se se- znamem všech vlastností.
4. Zde se může inspirovat již vytvořenými vlastnostmi nebo v horní části stránky mezi nadpisem a tabulkou kliknout na odkaz „Vytvořit novou +“.
5. Nyní se nachází na interaktivním formuláři. Napíše název vlastnosti a zvolí si požadovaný typ. Pokud si vybere typ „výběr“, objeví se mu další položka formuláře. V této části formuláře napíše všechny položky výběru a oddělí je oddělovačem. Konkrétně středníkem.
6. Jakmile je se svou novou vlastností spokojený, klikne na tlačítko
„Uložit“ a vlastnost se uloží. Aplikace uživatele přenese zpět na seznam všech vlastností, kde si může najít tu svou.
3.5.3 Přihlášený uživatel s administrátorskými právy
• Vytváření nového řádu či druhu.
1. Přihlášený uživatel se nachází na hlavní stránce. V horizontálním menu klikne na položku databáze.
2. Zobrazí se mu stránka výběru části databáze a uživatel klikne na odkaz „Řády“ či „Druhy“.
3. Nyní se nachází na seznamu všech záznamů. Kliknutím na odkaz
„Vytvořit nový“ v horní části stránky se přesune na novou stránku s formulářem.
4. Formulář náležitě vyplní. V případě nového druhu obsahuje formu- lář navíc povinný záznam řádu, do kterého druh spadá.
5. Kliknutím na tlačítko „Uložit“ se uloží do databáze nový záznam.
• Celkový průběh vytvoření modulu řádu či lokality.
1. Přihlášený uživatel se nachází na hlavní stránce. V horizontálním menu klikne na položku „Moduly“.
2. Zobrazí se mu stránka s výběru modulů a vlastností. Předpoklá- dejme, že uživatel již má vytvořené vlastnosti, které chce mít ve svém modulu. Uživatel klikne na odkaz „Modul lokality“ či pouze
„Modul“.
3. Tím se dostal na seznam všech modulů daného typu. V horní části stránky klikne na odkaz „Vytvořit nový“, který ho přesměruje na formulář.
4. Formulář obsahuje název modulu a list všech vlastností, které v mo- dulu mohou být. Uživatel si pomocí klávesy ctrl vybere více vlast- ností. Jakmile je s volbou spokojený klikne na tlačítko „Uložit“.
26
3.6. Zabezpečení
• Prohlížení uživatelů a určování jejich práv.
1. Přihlášený uživatel klikne na kolonku horního horizontálního menu s nápisem „Účet“.
2. Zobrazí se mu informace o jeho účtu. Zde v horní části stránky klikne na odkaz se zelenou šipkou „Seznam uživatelů“.
3. Tím se jako administrátor dostane na seznam všech uživatelů, kde přehledně vidí unikátní ID každého. Vybere si uživatele, kterého chce jmenovat administrátorem a do adresního řádku za/uživatel/
připíše /nastavitadmin/ a ještě přidá ID uživatele, kterého chce nastavit jako administrátora. Adresní řádek bude tedy vypadat například následujícím způsobem:webovaaplikace.cz/uzivatel/
nastavitadmin/4.
4. Poté se pokusí načíst si stránku z adresního řádku například stisk- nutím klávesy enter a aplikace danému uživateli přidá administrá- torská práva.
Stejným způsobem pouze změněním adresního řádku místo/nastavitadmin/
na/nastavituser/, sebereme administrátorská práva danému uživateli.
3.6 Zabezpečení
Veškeré informace vkládané do aplikace jsou sdíleny pouze napříč aplikací a jsou uložené v databázi. Vycházím z analýzy a přihlašování do aplikace bude probíhat již zmíněnou vylepšenou formou vyplnění formuláře s uživatel- ským jménem a heslem, které se ihned převede na hash algoritmem bcrypt a samotné heslo se neuloží do databáze. Chování uživatelů v aplikaci se řídí jednotlivými rolemi a jejich právy. Pokud se uživatel pokusí provést akci nebo navštívit stránku, na kterou nemá dostatečná práva, zobrazí se mu stránka s přihlašovacím formulářem nebo stránka s výjimkou obsahující zprávu o po- rušení práv. Vstup do aplikace bude chránit firewall. Všechny URL projdou hlavním firewallem a ten je prověří a popřípadě omezí jejich přístup.
3.7 Datový model
Datový model patří k těm nejdůležitějším částem projektu. Popisuje, jakým způsobem jsou uložená data a jaké jsou mezi nimi relace. Z analytické části vím, jaké entity musí být v databázi. Všemi entitami jsou: uživatel, řád, druh, jedinec, modul, modul lokality, vlastnosti, a pozorování. Pro každou entitu musí být v databázi jedna tabulka. Všechny tabulky, kromě spojových, obsa- hují atribut unikátního identifikátoru, který jasně definuje konkrétní záznam v tabulce. Při textovém popisu uvedu kardinalitu a parcialitu, avšak nebudu uvádět konkrétní cizí klíče, které však pro úplnost budou na obrázcích. Nyní
3. Návrh
rozeberu jednotlivé entity/tabulky a následně relace mezi nimi. Následuje di- agram 3.9 celého databázového modelu.
Obrázek 3.9: Databázový model
Uživatel Tabulka uživatele slouží převážně k přihlašování a pozorování. Ob- sahuje identifikační informace, uživatelské jméno, heslo, jméno, email, 28
3.7. Datový model telefon, role a data. Uživatel má rovnou dvě relace pouze s pozorová- ním. První relace/vazba je typu 0-1 ku N směrem od uživatele k po- zorování. Tato relace určuje autorství daného pozorování, tedy jakmile je vytvořeno nějaké pozorování, hned se propojí s jeho autorem. Druhá relace je typu N ku 0-1 a určuje jaké pozorování si nastavil konkrétní uživatel jako aktivní. To samé pozorování však může mít nastaveno více uživatelů jako aktivní.
Řád Tabulka řádu uchovává informaci o názvu, latinském názvu a obrázku řádu. Řád je největší nadmnožina jedinců v databázi. Řád je propojen se dvěma tabulkami a těmi jsou druh a pozorování. Pod jeden řád může spadat více druhů, tedy vazba je typu 1 ku N směrem od řádu k druhu.
Každé pozorování je zaměřeno na jedince druhů právě jednoho řádu, tedy více pozorování může pozorovat stejný řád. Z této informace vím, že relace je typu 1 ku N směrem od řádu k pozorování.
Druh Tabulka druhu uchovává název a zkratku druhu. Je v již zmíněné re- laci s řádem. Druhá a poslední relace je s jedincem. Pod jeden druh může patřit více jedinců, takže vazba je typu 1 ku N směrem od druhu k jedinci.
Jedinec Tabulka jedince uchovává pouze datum a čas pozorovaného jedince.
To se může na první pohled zdát zavádějící, ovšem kvůli požadavkům bylo nutné samotné naměřené hodnoty párovat s vlastnostmi. Tabulka jedince spadá celkem do tří relací a to s tabulkami druh, pozorování a hodnota. Relace s tabulkou druhu je již výše popsaná. Další relace s hodnotou zde byla již nastíněná. Konkrétní jedinec má jednu či více hodnot a daná hodnota patří právě tomuto jedinci. Vazba je tedy typu 1 ku N směrem od jedince k hodnotě. Poslední relace je s pozorováním. Při pozorování se může zapsat více jedinců a u každého je uloženo, v jakém pozorování byl objeven. To je vazba typu N ku 1, směrem od jedince k pozorování.
Hodnoty Tabulka hodnot je spojová tabulka mezi tabulkou jedince a vlast- nostmi, rozšířená o atribut hodnota. Spojuje konkrétního jedince s kon- krétní vlastností. Relace s jedincem byla vysvětlena v minulém odstavci.
Relace s vlastností je typu 1 ku N, směrem od vlastnosti k hodnotě.
Vlastnosti Tabulka vlastnost určuje název vlastnosti, její typ a v případě volby výběru i data výběru. V atributech vlastnosti není samotné místo pro uložení hodnoty dané vlastnosti. Je tomu tak, protože na jednu vlastnost může být pozorování více jedinců a hodnoty by se postupným plnění tabulky přepisovaly. Jedinec může mít zároveň více vlastností.
Vlastnost tedy musí být v relaci N ku M s jedincem. Při relaci typu N ku M se relace rozpadá na novou tabulku a dvě relace typu 1 ku N.
3. Návrh
Touto novou tabulkou je tabulka hodnoty, která zařídí řádné propojení vlastnosti a jedince.
Modul Tabulka modul má atribut název modulu. Tabulka slouží k modu- laritě vlastností modulů pozorování, tedy k tomu, aby si uživatel mohl zvolit pozorování, které bude mít právě jeden konkrétní modul (modul řádu) a ten bude mít nějaké vlastnosti. Modul je tedy v relaci s pozoro- váním a s vlastností. Relace s pozorováním je typu 1 ku N směrem od modulu k pozorování, protože tentýž modul může být obsažen ve více po- zorováních. Relace s vlastností by byla typu N ku M, proto se rozpadne na novou spojovací tabulku s názvem modul_vlastnost, která má dvě relace typu N ku 1 směrem od tabulky modul_vlastnost k tabulkám modul a vlastnost. Nová tabulka zajistí jejich řádné propojení.
Modul lokality Tabulka modulu lokality se dá chápat stejným způsobem, jako tabulka modul (modul řádu). Má obdobné relace, přičemž jedna se opět rozpadne na spojovou tabulku s dalšími relacemi.
Pozorování Tabulka pozorování je jedna z nejkomplexnějších z celého mo- delu. Spojuje totiž část databáze s jedinci, část s moduly i uživatele.
Každý záznam v tabulce pozorování nese informace o zvoleném modulu řádu a modulu lokality, řádu, uživatelích a jedincích.
3.8 Offline mód
Z analýzy procesů jsem zjistil, že při zapisování dat při pozorvování bude uživatel prakticky používat jen jednu stránku. Na této stránce je formulář vygenerovaný podle všech vlastností modulu řádu daného pozorování. Budu odchytávat stav internetového připojení a upravovat stránku tak, aby uživa- tel tento stav viděl. Pokud uživatel vyplněný formulář potvrdí, zkontroluje se stav připojení. Častým problémem při přidávání cookies je, že uživatel neví, k čemu slouží a může si je smazat. V případě této webové aplikace by však při- šel o dočasně uložené napozorované jedince v offline módu, kteří ještě nejsou synchronizovaní s aplikací. Jestliže je při odeslání formuláře uživatel offline, bude informován o uložení právě vyplněného jedince do cookies (viz obrázek 3.10). Tato akce se následně provede. Uživateli se objeví nová část na stránce pod formulářem s napozorovanými jedinci offline. Tito jedinci jsou sice v čás- tečně nečitelném formátu, ale uživatel vidí, že přibyl další a má tím pádem jakousi zpětnou vazbu o zaznamenání pozorování. V sekci webu s účtem při- hlášeného uživatele je k dispozici odkaz synchronizovat. Po kliknutí na tento odkaz je odeslán požadavek na server. Při analýze jsem zjistil, že cookies se přenáší na server s každým požadavkem. Na serveru tím pádem mohu z po- žadavku tyto cookies získat. Jednotlivé jedince v cookies ukládám pod název, kterým je aktuální číslo. Toto číslo slouží také jako dočasný unikátní identifi- 30
3.8. Offline mód kátor, takže mohu na serveru zjistit, o jakého přesně jedince se jedná a uložit k němu potřebné informace.
Obrázek 3.10: Upozornění na zaznamenávání offline
Kapitola 4
Implementace
Po analýze a návrhu přichází na řadu implementační část. Nejdříve jsem se roz- hodl, jaké vývojové prostředí budu používat a zvolil jsem si PhpStorm IDE od JetBrains. V tomto prostředí se mi dobře pracovalo, protože umožňuje nahlí- žení do databáze v reálném čase a umí spolupracovat s frameworkem Symfony a šablonovacím systémem Twig. Díky této funkci jsem mohl kontrolovat pro- vedené změny efektivně. Webové aplikace založené na jazyku PHP je potřeba vyvíjet na spuštěném serveru. Open source webový server XAMPP pro mě byl jasnou volbou, protože je zdarma a mám s ním již zkušenosti. Používám na něm Apache HTTP server a MySQL databázové prostředí. V PhpStorm jsem si nainstaloval a aktivoval Symfony plugin, PHP Toolbox a PHP Annotations.
4.1 Framework a bundly
Webové aplikace se dají vyvíjet od začátku za pomoci různých jazyků. Je to velice zdlouhavé, až kontraproduktivní. Existují na to takzvané frameworky, které nabízí použití kvalitních knihoven a ty dělají mnoho práce za programá- tora, který tak již nemusí vymýšlet tolikrát vymyšlené základy [14]. Mezi nej- používanější frameworky založené na programovacím jazyku PHP patří Sym- fony, Nette a Zend Framework. Ačkoliv Nette je velice kvalitní framework zalo- žený v České republice, budu tuto webovou aplikaci dělat v neméně kvalitním Symfony, protože v něm mám nejvíce zkušeností. Symfony je založený na kla- sickém webovém návrhovém vzoru Model view controller (MVC) [15], který, jak jsem ukázal v části návrhu, je pro webovou aplikaci tohoto rozsahu ideální.
Webové aplikace vyvíjené pomocí Symfony frameworku mají výhodu ve své modularitě, protože se do Symfony dají přidávat takzvané bundly. Bundle je zásuvný modul, který navyšuje možnou funkcionalitu. Symfony nabízí přes 20 oficiálních bundlů a podporuje velkou skupinu těch neoficiálních. Samotné pro- pojení bundlů zajištuje Symfony flex, což je plugin od Symfony do composeru.
Composer slouží k propojení závislostí jednotlivých modulů. Je obzvláště uži-
