Sem vložte zadání Vaší práce.

Transkript

1 Sem vložte zadání Vaší práce.

2

3 České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství Bakalářská práce IS pro lesní hospodářskou evidenci - frontend Petr Gregor Vedoucí práce: Ing. Jiří Hunka 16. května 2013

4

5 Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl 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ů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle 60 odst. 1 autorského zákona. V Praze dne 16. května

6 České vysoké učení technické v Praze Fakulta informačních technologií c 2013 Petr Gregor. 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ředpisy 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 licencí, je nezbytný souhlas autora. Odkaz na tuto práci Gregor, Petr. IS pro lesní hospodářskou evidenci - frontend. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.

7 Abstract Goal of this thesis is to analyze requirements for forestry filing system and then to design, implement and test its user interface. In the beginning you can find requirements analysis followed by user interface design. Next part deals with implementation and testing of prototype, which can be found on attached CD. GUI, Frontend, Requirements analysis, Implementation, Usa- Keywords bility testing Abstrakt Cílem této práce je provést analýzu požadavků na systém lesní hospodářské evidence a posléze pro tento systém navrhnout,implementovat a otestovat uživatelské rozhraní. Na začátku písemné části můžete nalézt analýzu problematiky a požadavků, kterou následuje návrh uživatelského rozhraní. Dále se práce zabývá implementací a testováním prototypu, který se nachází na přiloženém CD. vii

8 Klíčová slova GUI, Frontend, Analýza požadavků, Implementace, Testování použitelnosti viii

9 Obsah Úvod 1 1 Analýza Analýza problematiky Analýza požadavků Existující řešení Návrh uživatelského rozhraní Cílová skupina Prostředí Postup Použitý nástroj Uživatelské rozhraní Návrh architektury Umístění frontend Komunikace s backend Implementace Výběr technologie MVC Framework Další použité technologie Úskalí Výsledek Testování použitelnosti 41 ix

10 5.1 Kolikrát a kdy testovat? Na kolika lidech testovat? Koho testovat? Zásady Testování LHE Závěr 45 Literatura 47 A Seznam použitých zkratek 53 B Scénář testování s uživateli 55 B.1 Hospodářská kniha B.2 Evidence zásahů B.3 Organizační dělení C Obsah přiloženého CD 57 x

11 Seznam obrázků 1.1 Stránka z hospodářské knihy Evidenční stránka v hospodářské knize Evidenční lístek Uživatelské rozhraní PDS_ProPla Uživatelské rozhraní Field-Map LHE Uživatelské rozhraní Výroby Uživatelské rozhraní systému LesIS Layout google.com Layout aukro.cz Návrh základního rozložení stránky Návrh stránky zásahy Návrh stránky dodávky Návrh stránky hospodářská kniha Návrh stránky přehled Návrh stránky sestavy Návrh stránky nastavení uživatelů Návrh stránky nastavení výkonů Návrh stránky nastavení organizačního dělení Návrh stránky nastavení sortimentu Možnosti umístění frontend xi

12

13 Úvod Les pokrývá přibližně třetinu celého území České republiky[30]. Je naším přírodním bohatstvím, zdrojem dřeva a nenahraditelnou složkou životního prostředí. Z těchto důvodů je třeba ho chránit a zachovat pro budoucí generace. [48] Pro zajištění ochrany a správného nakládání s lesem vznikl lesní zákon. V jeho současné podobě nařizuje, mimo jiné, vlastníkům větších částí lesa zajistit zpracování lesního hospodářského plánu (LHP) a vedení lesní hospodářské evidence (LHE).[52] Zadavatel této práce, firma Lesprojekt východní Čechy, s.r.o., chce nabídnout program usnadňující vedení LHE. Navíc tento program plánuje využít k navázání užší spolupráce se svými zákazníky, pro které v současnosti jednou za 10 let zpracovává LHP a dále k usnadnění tvorby LHP u vlastníků, kteří budou systém používat. Celý projekt je vzhledem ke svému rozsahu rozdělen na dvě části. Tato se zabývá pouze uživatelským rozhraním systému, zatímco druhá, zpracovávaná Jiřím Müllerem, řeší jádro systému. Cílem práce je provést analýzu, návrh, implementaci a testování uživatelského rozhraní systému k vedení LHE, který splní zákonné požadavky, požadavky zadavatele a navíc pomůže správci lesa s organizací, kontrolou a evidencí prací v lese. 1

14

15 Kapitola 1 Analýza 1.1 Analýza problematiky Protože lesnictví je obor informatice velmi vzdálený, je třeba před začátkem práce na analýze požadavků provést analýzu problematiky. V této části práce se pokusím zjednodušeně vysvětlit pojmy a vztahy, které se objevují na dalších stránkách. Většina informací zde uvedených byla získána přímo od zástupců zadavatele nebo při komunikaci s budoucím uživatelem systému Správce lesa V této práci označuji termínem správce lesa subjekt spravující LHE. Může to být například odborný lesní hospodář (OLH), vlastník lesa nebo vlastníkem najatá firma Základní rozdělení lesa Pro evidenci je velmi důležité dělení a identifikace částí lesa. Nejvyšší jednotkou dělení je lesní hospodářský celek (LHC). Jedná se o celek s jedním vlastníkem o maximální rozloze ha a označující se číslem (například ). Celky se dále dělí na oddělení, dílce, porosty, porostní skupiny a etáže. Výměra oddělení běžně nepřesahuje 150 ha a označuje se číslem. Dílce běžně nepřesahují rozlohu 50 ha a značí se velkým písmenem. Další jednotkou jsou porosty, značené malým písmenem, které se dále dělí na porostní skupiny. 3

16 1. Analýza Porostní skupina je nejmenší jednotka plošného rozdělení. Jedná se o spojitou část lesa, která se shoduje ve věku a druhové skladbě. Porostní skupina se značí číslem určeným podle věku a stejně staré porostní skupiny v jednom dílci se navíc odlišují pomocí malého písmene za číslem. V každé porostní skupině je minimálně jedna etáž, tedy jakési patro lesa. Ve většině porostních skupin je etáž právě jedna, ale stavá se, že na jedné ploše rostou současně různě staré stromy. Jde například o případy, kdy pod 140letýmy velikány roste 10letá mlazina. V této situaci slouží etáže k rozlišení těchto pater lesa. Etáže používají stejné značení jako porostní skupiny. Pokud porostní skupina obsahuje více etáží, je její označení složeno z označení etáží oddělených lomítkem. Kompletní identifikace části lesa v rámci ČR tedy může být například: J-a-9-9 nebo B-a-13a/3-13a Lesní hospodářský plán Lesní hospodářský plán (LHP) je periodická invetura lesa (typicky každých 10 let) a stanovení mezí jeho využívání prostřednictvím tzv. závazných ustanovení. LHP tedy zachycuje momentální stav lesa a navíc určuje, jak by se mělo nebo jak se musí dále s lesem nakládat [25]. LHP zpracovávají odborné firmy a správci lesa předají již hotový produkt. Část plánu relevantní k LHE je hospodářská kniha. Jedná se o dokument obsahující informace o stavu jednotlivých částí lesa (s přesností na etáže) a návrh hospodářských opatření v nich na dalších 10 let. Všechny tyto údaje jsou dnes naštěstí dostupné také v digitální formě, která podléhá standardizaci ministerstvem zemědělství [51]. Jak vypadá papírová verze této knihy se můžete podívat na obrázku Lesní hospodářská evidence Podle zákona [52] je LHE evidence o plnění závazných ustanoveních lesního hospodářského plánu a evidence o provedené obnově lesa v jednotlivých porostech. Spočívá v tom, že si správce lesa zapisuje veškeré zásahy, které v dané části lesa proběhly, včetně přirozeného zalesnění náletem nebo poškození lesa přírodní kalamitou. V ideálním případě by se měl aktuální stav lesa rovnat stavu zachyceném v LHP po započítání všech zásahů z LHE. Souhrné údaje z LHE je vlastník povinnen předat státní správě lesů každý rok [52]. 4

17 TopolPro Analýza požadavků Oddělení: Plocha: Majitel: LO: LHC: Platnost: Strana: 1 6,33 4/1 23 Podkrkonoší Díl.: Por. : Plocha: Kategorie/překryv: Zvl.St.: Pásmo ohrož: LS(LZ): OLH: B a 6,33 32e 15 - Ochranné pásmo vodního D Obec Malá Skála Zdeněk Brožek zdroje - II.stupně - vnitřní 18 - CHOPAV 39 - les se zvýšenou funkcí půdoochrannou 99 - jiný veřejný zájem Popis porostu: BO porost na prudkém, kamenitém, S a JV svahu plnící půdoochr. až ochrannou funkci, v SV části započato s obnovou. CHOPAV Severočeská křída. Přírodní park Maloskalsko. Součást RBK Malá Skála- Suché skály. PHO 2a. 0 0,30 Les.typ: 3S Turnov Vranové I Por.skupina: Plocha por.skup.: LVS: ORP : Kód KÚ: Název KÚ: Popis por.skup: Zabuřenělá holina s ponechanými výstavky SM,DB a KL, starší předrosty KL. BK zalesnit ve dvojsadbě se SM. Hosp. soubor Věk Dřevina Výč. tloušťka Výška Obj.stř. kmene ULT Bonita abs. Bon.rel. 3/2008Sb Fenot. třída 100/30 25% Model.těž.%: Obmýtí / Obn.doba: % mel. a zpevň.dřevin: % cm m m3 b.k. Poškození Zásoba v m3 b.k. Těžba výchovná Těžba obnovní Prořezávky Zalesnění Zakmenění Zastoupení Na 1 Druh % Imise ha Souše Celkem Plocha Objem Plocha Objem Plocha Druh Dřevina v % ha Zast Plocha pl.et. ha m3 ha m3 ha SM 70 0,21 BK 30 0,09 Por.sk.celkem: ,30 1 0,57 Les.typ: 0K Turnov Vranové I Por.skupina: Plocha por.skup.: LVS: ORP : Kód KÚ: Název KÚ: Popis por.skup: Zabuřenělá, mezernatá kultura s ponechanými výstavky DB a BK, starší předrosty BK. DG,BR +. Vylepšit - BK do dvojsadby se SM. 120/20 Model.těž.%: Obmýtí / Obn.doba: % mel. a zpevň.dřevin: SM SM 70 0,11 DB BK 30 0,04 JD BK Por.sk.celkem: ,15 2 0,84 Les.typ: 3S Turnov Vranové I Por.skupina: Plocha por.skup.: LVS: ORP : Kód KÚ: Název KÚ: Popis por.skup: Různorodá mlazina skup. smíšená, JV,JS,OL,JR +, výst. DB,DBC. 2 části. 100/30 Model.těž.%: Obmýtí / Obn.doba: % mel. a zpevň.dřevin: SM DB BO KL MD , BK BR , Por.sk.celkem: ,84 Naléh. Násob. Naléh. Násob. Obrázek 1.1: Stránka z hospodářské knihy 1.2 Analýza požadavků Analýza požadavků je proces hledání opravdových požadavků, tedy takových, které odpovídají ověřené potřebě uživatele na specifický systém nebo funkčnost [50]. Je důležité věnovat na tuto práci dostatek prostředků, asi 10-30% celku [37], protože vše ostatní na ní stojí a padá. Sběr požadavků pro tento projekt jsem provedl osobně u budoucího uživatele (správce lesa) a zadavatele. Požadavky a mé chápání celého problému se postupně vyvíjelo a bylo nutné každého navštívit několikrát. Během pozdějších fází jsem pro lepší porozumnění a usnadnění komunikace používal wireframe uživatelského rozhraní o kterém budu mluvit později. Bohužel jsem byl ve sběru požadavků u správce lesa omezen pouze na jeden subjekt, protože zadavatel nevyjednal spolupráci s dalšími. Před dokončením a nasazením systému je potřeba ověřit získané požadavky u více správců. 5

18 1. Analýza Požadavky zadavatele R1: Dostupnost dat provozovateli Kategorie: Nefunkční požadavek Popis: Všechna data, která uživatel do systému zadá, budou dostupná provozovateli, tedy firmě Lesprojekt východní Čechy, s.r.o. Zdůvodnění: Zadavatel (provozovatel) využije data poskytnutá správcem lesa v rámci používání systému při vytváření nového LHP. R2: Formát vstupních dat Kategorie: Nefunkční požadavek Popis: Vstupní data LHP budou do systému nahrávána ve formátu informačního standardu lesního hospodářství (ISLH). [51] Zdůvodnění: Výstup v ISLH podporují nejen programy používané zadavatelem, ale i programy používané konkurenčními firmami. R3: Napojení na existující infrastrukturu Kategorie: Nefunkční požadavek Popis: Část systému provozovaná na infrastruktuře zadavatele bude kompatibilní s virtualizačním systémem Xen Cloud Platform. Zdůvodnění: Zadavatel bude systém provozovat jako virtuální stroj ve své existující infrastruktuře. R4: Zabezpečení dat 6 Kategorie: Nefunkční požadavek Popis: Veškerá data přenášená nebo dostupná po internetu budou zajištěna proti odposlechu a neoprávněnému přístupu.

19 1.2. Analýza požadavků Zdůvodnění: Přístup neautorizované osoby k datům je nežádoucí. R5: Import dat LHC Kategorie: Funkční požadavek Popis: Zadavatel bude mít možnost importovat vstupní data LHP. Zdůvodnění: Před registrací nového správce lesa je třeba nahrát do systému patřičný LHP. R6: Správa uživatelů Kategorie: Funkční požadavek Popis: Zadavatel bude mít možnost vytvářet nové uživatele a nastavovat jim oprávnění správce LHC. Zdůvodnění: Veškeré registrace nových správců lesa budou řešeny ručně pracovníkem zadavatele. R7: Nahlížení do hospodářských knih Kategorie: Funkční požadavek Popis: Zadavatel bude mít možnost nahlížet do všech hospodářských knich v systému, včetně údajů o plnění plánu a provedených zásazích v jednotlivých částech lesa. Zdůvodnění: Zejména tyto informace budou využívány pro zjednodušení tvorby nového LHP Požadavky správce lesa R8: Nároky na OS Kategorie: Nefunkční požadavek 7

20 1. Analýza Popis: Zákaznická část systému pro LHE bude kompatibilní s OS Microsoft Windows XP Professional Service Pack 3 a novějším. Zdůvodnění: Na všech počítačích správce lesa je nainstalován OS Windows, na některých je ještě používán Windows XP. R9: Zobrazení lesní hospodářské knihy Kategorie: Funkční požadavek Popis: Systém umožní správci nahlížení do lesní hospodářské knihy. Zdůvodnění: Lesní hospodářská kniha obsahuje všechny potřebné informace o lese. Hledání těchto údajů v papírové verzi knihy je nepraktické. R10: Zadávání zásahů Kategorie: Funkční požadavek Popis: Systém umožní zadávání záznamů o provedeném zásahu v lese. Záznam může obsahovat: a) popis zásahu b) specifikaci druhu zásahu pomocí výkonu a podvýkonu c) označení lesa, kde byl zásah vykonán, s přesností na etáž d) ovlivněnou plochu etáže e) délku práce (strávený čas) f) množství vyprodukovaného/spotřebovaného materiálu (sazenice, dřevo...) g) dřevinu, které se zásah týká a její sortiment (kvalitu vzniklého dřeva) h) datum, kdy byl zásah proveden i) evidenční číslo dokladu o provedení práce. Povinné údaje jsou etáž, výkon, podvýkon a datum. Zdůvodnění: Na tomto zadávání stojí LHE. Ze všech provedených zásahů a jejich atributů se vypočítávají požadované výstupy. Evidenční číslo dokladu slouží k párování elektronického záznamu s papírovou evidencí. R11: Dodávky dřeva 8 Kategorie: Funkční požadavek

21 1.2. Analýza požadavků Popis: Systém bude veškeré vyprodukované dřevo zavedené do systému(r10) evidovat jako nedodané, dokud nebude přiřazeno do dodávky. Záznam o dodávce bude obsahovat identifikaci odběratele, datum a dále množství, kvalitu a původ dřeva. Zdůvodnění: Po těžbě dřevo často leží dlouhou dobu v lese a čeká na odvoz. Je třeba mít přehled o tom, kde je jaké dřevo k dispozici a hlídat, aby se neztratilo. R12: Výstupy Kategorie: Funkční požadavek Popis: Systém bude umožňovat alespoň tyto výstupy: a) výpis provedených zásahů filtrovatelný podle data, oblasti, výkonu, kategorie výkonu a dřeviny a seskupitelný podle oblasti, výkonu a kategorie výkonu b) výpis nedodaného dřeva c) výpis dodávek filtrovatelný podle dřeviny, etáže původu a odběratele d) souhrný výstup těžeb, výchovy a zalesnění pro celé LHC. Zdůvodnění: Tato data využívá správce lesa k plnění zákonných povinností a k plánování hospodaření v lese. R13: Delegování oprávnění Kategorie: Funkční požadavek Popis: Systém bude umožňovat správci lesa vytvářet nové uživatelské účty a delegovat jim oprávnění. Jakýkoli uživatel bude moci být omezen na určitý úsek lesa (středisko). Oprávnění budou uživateli přidělována pomocí předdefinovaných rolí. Systém bude obsahovat minimálně tyto: a) správce, má neomezená práva v rámci přiděleného střediska (nebo celého LHC) b) pracovník, všechna jeho činnost v systému podléhá schválení správcem. Zdůvodnění: Správce lesa obvykle nepracuje sám. Je žádoucí co nejvíce činností delegovat na podřízené, aby se mohl věnovat plánování a kontrole a nezdržovalo ho opisování lístků do systému. 9

22 1. Analýza R14: Správa organizačního dělení Kategorie: Funkční požadavek Popis: Vychází z R13. Systém bude umožňovat správu středisek. Středisko bude určeno svým jménem a přiřazenými částmi lesa. Z těchto středisek se bude vybírat při nastavování práv uživateli. Zdůvodnění: Na větších majetcích je správa lesa dále rozdělena na střediska. Každé středisko se zabývá hospodařením na přidělené části lesa. V tomto systému budou střediska využívána k usnadnění přiřazování práv uživatelům a zjednodušení filtrace. R15: Správa odběratelů Kategorie: Funkční požadavek Popis: Vychází z R11. Systém umožní vedení jednoduchého seznamu, ve kterém bude název, adresa a kontaktní telefon každého odběratele. Z tohoto seznamu bude možné vybrat odběratele při zadávání a filtraci dodávek. Zdůvodnění: Seznam bude sloužit k zjednodušení zadávání dodávek. R16: Správa výkonů Kategorie: Funkční požadavek Popis: Vychází z R10. Systém umožní vedení seznamu výkonů a podvýkonů. Z těchto seznamů bude možné vybírat při zadávání výkonu a při filtrování nebo seskupování výstupů. Výkon bude definován kódem, popisem, kategorií a používanými jednotkami času, plochy a množství. Podvýkon bude obdobný, ale navíc se bude vždy vázat na určitý výkon. Možné kategorie výkonu jsou: a) zalesnění b) výchova do 40 let c) těžba předmýtní úmyslná d) těžba předmýtní nahodilá e) těžba mýtní úmyslná f) těžba mýtní nahodilá. Zdůvodnění: Seznamy budou sloužit k zjednodušení zadávání zásahů a také budou usnadňovat filtraci. 10

23 1.3. Existující řešení R17: Správa sortimentu a výrobků Kategorie: Funkční požadavek Popis: Vychází z R10. Systém umožní vedení jednoduchých seznamů sortimentů a výrobků. Sortiment i výrobek jsou definovány jako kód a popis. Z těchto seznamů bude možné vybírat při zadávání zásahu a při filtrování dat. Zdůvodnění: Seznamy budou sloužit k zjednodušení zadávání zásahů a také budou usnadňovat filtraci. 1.3 Existující řešení Každý jehož se zákoná povinnost týká již LHE nějakým způsobem řeší. Ať už s pomocí dnes již spíše historických, ale stále funkčních papírových lístků nebo s pomocí specializovaného software. Zde proto uvádím krátký přehled mně známých prostředků k vedení LHE Papírová evidence Jedná se o nejstarší metodu. Využívá papírovou verzi hospodářské knihy k zapisování jednotlivých zásahů přímo k odpovídajícím etážím. Tento způsob vedení LHE je již díky rozvoji IT na ústupu, ale zvlástě na malých majetcích je stále rozšířený. Jako doplněk evidence v hospodářské knize mohou sloužit papírové lístky. Ty se stále používají pro zapisování v terénu, i když samotná LHE je již vedena digitálně. Data se z nich následně přepisují do počítače. Některé systémy již tento problém řeší pomocí aplikací pro tablety, mobily nebo PDA. Představu o zapisování evidence do hospodářské knihy a těchto lístků si můžete udělat z obrázků 1.2 a PDS_ProPla Program v nabídce firmy PDS s.r.o. využívaný největším vlastníkem lesa v České Republice, kterým jsou Lesy České republiky, s. p. Jedná se o nástroj odborného lesního hospodáře pro práci se všemi informacemi o lese. Jednou z jeho funkcí je i vedení LHE [35]. PDS_ProPla je aplikace pro operační systém Microsoft Windows, její uživatelské rozhraní si můžete prohlédnout na obrázku

24 1. Analýza Lesní hospodářská evidence: Odd. Díl. Por. 1 B a Por.skupina Etáž Rok Druh těžby Těžby Zalesnění Dřevina Dřevina Umělá obnova Celkem Těžební (probírková) plocha Por.skupina Etáž Rok m3 hroubí bez kůry na dvě desetinná místa ha Sem. v kg, saz. v 1000 ks ha ha První Opakované Celkem Přirozená obnova Podsadba Prořezávka Poznámka Obrázek 1.2: Evidenční stránka v hospodářské knize Field-Map LHE Produkt firmy IFER - Ústav pro výzkum lesních ekosystémů, s.r.o. s mnoha funkcemi. Mimo jiné umožňuje i editaci lesnické mapy, propojení s GPS zařízením a synchronizaci s centrální databází. Umožňuje také zadávání dat na mobilním zařízení přímo v terénu [15]. Ukázku uživatelského rozhraní přikládám na obrázku Výroba 3000 Výroba je v Delphi napsaný produkt firmy IterSoft s.r.o. Choceň. Tento program je určený pro vedení lesní a hospodářské evidence, odbytové a analyticko-finanční řízení [18]. Na obrázku 1.6 si můžete prohlédnout jeho uživatelské rozhraní. 12

25 1.3. Existující řešení Obrázek 1.3: Evidenční lístek LesIS Dle tvůrce, Multimedia atelier s.r.o., je LesIS specializovaný komplexní software pro správu lesnického provozu. Umožňuje výběr dodavatelů, projektování a důkladnou kontrolu průběhu lesnické výroby, včetně evidence dříví [32]. Systém vznikl jako zakázka pro NP a CHKO Šumava, kde je nyní nasazen. Je zajímavý zejména svým webovým rozhraním a aplikací pro operační systém Android. Screenshot z LesISu naleznete na obrázku

26 1. Analýza Obrázek 1.4: Uživatelské rozhraní PDS_ProPla Obrázek 1.5: Uživatelské rozhraní Field-Map LHE 14

27 1.3. Existující řešení Obrázek 1.6: Uživatelské rozhraní Výroby 3000 Obrázek 1.7: Uživatelské rozhraní systému LesIS 15

28

29 Kapitola 2 Návrh uživatelského rozhraní 2.1 Cílová skupina Před začátkem návrhu je nutné co nejpřesněji specifikovat, kdo bude uživatelem systému. Tedy na jakou demografickou skupinu se má zaměřit. Přestože je program zacílen hlavně na menší lesní majetky, tak bude každý správce lesa odborníkem v lesním hospodářství. Zákon vyžaduje, aby měl OLH buď vysokoškolské lesnické vzdělání a 3 roky praxe nebo středoškolské lesnické vzdělání a 10 let praxe [52]. Většina správců bude tedy starší třiceti let se zakončenou lesnickou školou. Toto ovšem nemusí platit pro spolupracující osoby, kterým správce umožní přístup do systému podle R13. Tito uživatelé ale budou nejčastěji pracovat pod dohledem a podle instrukcí správce lesa. Důležitým faktem je, že správce ani spolupracující osoby nebudou odborníky v IT. Jejich zkušenosti budou většinou omezené na základní používání kancelářských aplikací, webového prohlížeče a u. 2.2 Prostředí Na jakých systémech musí rozhraní fungovat? Bude se ovládat dotykově nebo myší? Bude to webová nebo desktop aplikace? Odpovědi na tyto otázky významně ovlivňují požadavky R8 a R1. Vyplývá z nich, že rozhraní bude používáno na běžných kancelářských počítačích a aplikace bude pro svůj běh vyžadovat internetové připojení. Rozhraní se tedy bude ovládat pomocí klávesnice a myši a bude implementováno buď jako webová aplikace, nebo jako standardní desktop aplikace, která ale nebude fungovat bez připojení k internetu. 17

30 2. Návrh uživatelského rozhraní Web vs. Desktop Toto je problém, který v posledních letech řeší mnoho lidí (a firem) [13] [27]. S nástupem HTML5 jsou totiž webové aplikace schopny konkurovat desktopovým v mnoha nových směrech [31]. Zde porovnám obě řešení pro tento konkrétní případ Instalace a aktualizace Jednou z největších výhod webových aplikací je absence instalace [13]. Jediné co uživatel musí pro spuštění udělat, je zadat do prohlížeče správnou adresu. Aplikace je tedy úplně nezávislá na konkrétním počítači a spustitelná téměř kdekoli. Současně se tím řeší problém aktualizací. V případě desktop aplikace je buď nutné implementovat automatické aktualizace, nebo musí uživatel instalovat každou novou verzi ručně Závislost na platformě Webová aplikace bude fungovat všude, kde je nainstalován webový prohlížeč. Pro LHE sice není tato nezávislost kritická, ale umožnila by provoz systému bez dalších úprav například na tabletech. Za nezávislost na platformě ovšem webová aplikace platí nutností řešit kompatibilitu mezi různými prohlížeči, což brzdí vývoj Závislost na připojení k internetu Nezávislost na internetovém připojení bývá hlavní výhodou desktopových aplikací. V tomto případě to ale díky požadavku R1 neplatí. Jediná výhoda, která tomuto řešení zůstává, je menší náročnost na objem přenesených dat. Desktopová aplikace přenáší pouze data, zatímco webová aplikace i programový kód. Nárůst objemu je řádově ve stovkách kb až jednotkách MB, ale projeví se pouze jednou, při prvotním načtení aplikace. Většina lidí v ČR je připojena k internetu rychlostí větší než 2Mb/s [53]. Při předpokladu jednoho MB dat navíc, to pro většinu uživatelů znamená čekání menší než 4s. Každé další načtení na stejném počítači bude díky cache ještě rychlejší Výběr Po zvážení obou řešení jsem se rozhodl jít cestou webové aplikace. Okamžitý přístup k nejnovější verzi bez nutnosti instalace a odkudkoli je důležitější, než občasná krátká prodleva během jejího spouštění. Nezávislost na platformě je další výhoda tohoto přístupu. 18

31 2.3. Postup 2.3 Postup Kvalitní uživatelské rozhraní není téměř nikdy možné vytvořit na první pokus. Je třeba postupně hledat správnou cestu. Při návrhu jsem nejprve vytvořil hrubý prototyp každé stránky a poté jsem ho za pomoci principů kognitivního průchodu několikrát revidoval. Jako další krok jsem návrh předložil budoucímu uživateli nebo odborníkovi z oboru, aby zkontrolovali vhodnost a úplnost rozhraní pro daný úkol. Tímto postupem jsem se snažil co nejvíce omezit množství chyb, které v návrhu zůstanou až do fáze implementace. 2.4 Použitý nástroj Protože je každý návrh několikrát přepracováván a upravován, vyplatí se použít nástroj, s jehož pomocí je tvorba a úprava návrhů velmi rychlá. Já se rozhodl pro program Pencil[9]. Jedná se o multiplatformní nástroj pro vytváření GUI mockupů, který obsahuje velké množství předpřipravených tvarů a typů rozhraní. Navíc je dostupný zcela zdarma. Pencil umožňuje vytvořené návrhy exportovat buď jako obrázky nebo jako html stránky, které mohou být provázány funkčními odkazy. 2.5 Uživatelské rozhraní Layout První věcí, kterou je potřeba se zabývat, je celkové rozložení prvků na stránce. Vyplatí se vycházet z obecně používaných vzorů, protože lidé jsou na ně zvyklí a snadněji se pak v systému orientují. Navigační prvky bývají umístěny v horní a/nebo levé části stránky a obsah ve středním sloupci. Informace o přihlášeném uživateli se nejčastěji nachází vpravo nahoře. Takto jsou řešené například tyto weby, které patří v ČR k nejnavštěvovanějším 1 : facebook.com, google.cz (obrázek 2.1), youtube.com, idnes.cz, wikipedia.org a aukro.cz (obrázek 2.2). Protože v systému pro LHE nebude velké množství navigačních odkazů, rozhodl jsem se pro využití horizontálního panelu, který zabírá méně místa než panel vertikální. Je zde umístěna celá navigace, ze které je zároveň evidentní, kde v systému se uživatel právě nachází (zvýraznění aktuálního odkazu). Také tu je menu uživatele, které slouží k odhlášení, změně hesla 1 Podle [4] patří tyto weby do prvních dvaceti nejnavštěvovanějších z ČR. Weby 19

32 2. Návrh uživatelského rozhraní a indikaci, kdo je právě přihlášen. Dalším prvkem na panelu je výběr LHC. Uživatel s přístupem do více LHC si pomocí něj může zvolit, se kterým chce pracovat. Náčrt layoutu je na obrázku 2.3 Obrázek 2.1: Layout google.com Zásahy Na stránce zásahy budou uživatelé vytvářet a editovat záznamy o provedených zásazích v lese. Za tímto účelem se zde nachází tabulka s řádkovou editací. Toto řešení je pro systém LHE lepší než editace s pomocí zvláštního formuláře, protože více připomíná papírový evidenční lístek a také tabulkový procesor, se kterým jsou uživatelé často zvyklí pracovat. Tato stránka není určena pro poskytování komplexních výstupů, přesto se zde nachází skrývatelný filtr, který slouží k zpětnému dohledání záznamu pro editaci. Při zadávání nového zásahu nejprve uživatel zkontroluje a případně upraví jeho datum. Po aktivaci tohoto políčka, které se nachází vlevo pod tabulkou zásahů, se objeví malý kalendář, ze kterého je možné datum vybrat. Dále vyplní etáž. Příslušné vstupy nabídnou uživateli po aktivaci výběr ze všech možností, který se bude při psaní dále zužovat. Stejným způsobem funguje výkon, podvýkon, dřevina, sortiment a výrobek. Můžete si všimnout, že u naposledy zmíněných je černou šipkou naznačena možnost 20

33 2.5. Uživatelské rozhraní Obrázek 2.2: Layout aukro.cz Obrázek 2.3: Návrh základního rozložení stránky 21

34 2. Návrh uživatelského rozhraní výběru. V případě skupiny vstupů pro porost jsem se rozhodl toto označení vynechat kvůli jejich malé velikosti. Uživatele by mohlo políčko celé zaplněné černou šipkou mást. Dalším krokem při přidávání zásahu je vyplnění výkonu a podvýkonu, které opět proběhne výběrem z nabídky. Po vybrání podvýkonu se do následujícího políčka automaticky vyplní text složený z popisů výkonu a podvýkonu, lze ho ovšem v případě potřeby přepsat nebo doplnit. Také se v políčcích pro čas, plochu a množství objeví příslušné jednotky a políčka se stanou aktivními, aby je uživatel mohl použít. Pro dokončení záznamu může uživatel doplnit další údaje (dřevinu, sortiment, výrobek a evidenční číslo) tyto jsou ale stejně jako množství, čas a plocha nepovinné. K přidání do tabulky dojde po stisku tlačítka plus. Návrh si můžete prohlédnout na obrázku 2.4. Obrázek 2.4: Návrh stránky zásahy Dodávky Na této stránce najdou uživatelé přehled nedodaného dřeva, spolu s možností vytvářet, editovat a rušit dodávky. Editace seznamu nedodaného dřeva není třeba, protože vychází ze zadaných zásahů. Nutné je navázat záznamy 22

35 2.5. Uživatelské rozhraní o dřevu na záznamy o zásazích, při kterých toto dřevo vzniklo. To je zrealizováno pomocí ikony info, která po kliknutí zobrazí detail odpovídajícího zásahu. Při vytváření nové dodávky uživatel nejdříve kliknutím na šipku vybere ze seznamu nedodané dřevo. Do vkládací části tabulky s dodávkami se tím předvyplní část záznamu a zbývá doplnit pouze datum, odběratele a množství odebraného dřeva. Tímto způsobem lze přidat i více druhů dřeva do jedné dodávky. Celá akce se potvrdí přidáním do tabulky pomocí ikony plus, což je způsob používaný konzistentně v celém systému. Výsledný návrh je na obrázku 2.5. Obrázek 2.5: Návrh stránky dodávky Hospodářská kniha V hospodářské knize prohlížejí uživatelé informace o lese. Jedná se pouze o zobrazování, žádná editace zde neprobíhá. Téměř všechny uvedené informace jsou navíc statické (po počátečním importu dat z LHP se už nemění). Jedinou vyjímkou je část provedené zásahy, kde se zobrazují data zadaná na stránce zásahy. 23

36 2. Návrh uživatelského rozhraní Zobrazení odpovídá hierarchické struktuře základního rozdělení lesa. Na nejvyšší úrovni jsou informace o LHC, které jsou standardně skryty, protože se příliš často nepoužívají. Následují informace o porostech, porostních skupinách a etážích. I tyto lze pro přehlednost skrývat. V návrhu jsou takto skryty sekce LHC a Porost. Po rozbalení jsou úplně stejné jako sekce Porostní skupina, samozřejmě s jinými popisky a hodnotami. Pro zobrazení dat musí uživatel nejprve vybrat část lesa, o kterou má zájem. To provede pomocí selectů v levém sloupci. Po provedení výběru se zobrazí požadovaná data. U většiny polí je ikona info, která po najetí myši zobrazí tooltip s doplňujícím vysvětlením tohoto pole. Všechny popisy a doplňující vysvětlení jsou převzaty z informačního standardu lesního hospodářství [51]. Výsledný návrh se nalézá na obrázku Výstupy - přehled Na této stránce vidí uživatel přehled odvedené práce v hlavních kategoriích zásahů. Rozhraní umožňuje výběr období, za které má být výstup spočítán. Jedním z využití tohoto přehledu je pro hlášení souhrných údajů LHE státní správě lesů. Návrh je na obrázku Výstupy - sestavy Zde si uživatel může podle svých potřeb nakonfigurovat a následně zobrazit výpis zásahů. Zásahy je možné filtrovat a poté seskupovat. Filtrování podle zadaných hodnot omezí zásahy, které se berou při generování výstupu v úvahu. Seskupení vytvoří skupinu zásahů pro každou diskrétní hodnotu vybraného pole a pro každou tuto skupinu zobrazí součty množství, času a plochy. Ve výsledku to znamená, že je možné zjistit například kolik jaké dřeviny bylo minulý rok zasázeno (vyfiltruji kategorii zalesnění za období minulého roku a seskupím podle dřeviny) nebo kolik dřeva bylo vytěženo v jednotlivých střediscích (vyfiltruji pouze těžby a seskupím podle středisek). Návrh rozhraní je na obrázku Nastavení uživatelů Na větších majetcích se o les stará více než jedna osoba. Pomocí tohoto rozhraní může správce LHC umožnit svým spolupracovníkům přístup do systému. Každému může přidělit jednu nebo více rolí, které navíc mohou být omezeny na středisko. Při přidávání nejprve správce vyplní jméno a nového uživatele. Dále pomocí dvou selectů vybere středisko (nebo celé LHC) a požadovanou 24

37 2.5. Uživatelské rozhraní Obrázek 2.6: Návrh stránky hospodářská kniha roli. Po přidání všech požadovaných rolí potvrdí přidání uživatele pomocí ikony plus. Na zadaný přijde zpráva s instrukcemi, jak se do systému přihlásit. Popsaný návrh najdete na obrázku Nastavení výkonů Každý lesní provoz funguje jinak. Aby byl systém dostatečně flexibilní, umožňuje pomocí tohoto rozhraní nakonfigurovat pro každé LHC vlastní číselník výkonů a podvýkonů. Výkony reprezentují kategorie práce a pod- 25

38 2. Návrh uživatelského rozhraní Obrázek 2.7: Návrh stránky přehled výkony její užší specifikaci. Výkon může být například ochrana lesa a příslušné podvýkony mohou být kladení lapáků proti kůrovci, ovazování pletivem a chemický nátěr. Při úpravě nebo přidávání nových druhů práce uživatel nejprve v levé tabulce vybere stávající, nebo přidá nový výkon. V pravé tabulce je poté možné přidávat nebo editovat podvýkony náležící pod vybraný výkon. Ke každému podvýkonu je možné přiřadit jednotku množství, času a plochy. Tyto jednotky se budou zobrazovat při následném přidávání zásahů. Pokud není jednotka vybrána, předpokládá se, že zadávání této veličiny nemá pro daný podvýkon smysl a formulář zásahů ho neumožní. Zadání kategorie je nepovinné a slouží k rozdělení výkonů do obecných kategorií, ze kterých poté systém vytváří výstupy. Návrh rozhraní je na obrázku Nastavení organizačního dělení Na této stránce je možné definovat střediska, která v systému reprezentují množiny částí lesa. Při přidávání uživatel nejprve vyplní název nového střediska a následně do dalších polí podle potřeby zadá oddělení, dílec, porost a porostní skupinu. Poté může přidat další části lesa pomocí nových prázd- 26

39 2.5. Uživatelské rozhraní Obrázek 2.8: Návrh stránky sestavy ných polí, která se objeví po odkliknutí původních fajfkou. Celou akci potvrdí opět stiskem tlačítka plus, což přidá nový řádek do tabulky. Jak je vidět na obrázku 2.11, je možné zadat neúplnou identifikaci části lesa. Například pouze oddělení. V tom případě bude do střediska náležet celé vybrané oddělení a ne jen jeho část Nastavení výrobků, sortimentu a odběratelů Na těchto stránkách se nachází tabulky umožňující editaci dalších číselníků v systému. Všechny vypadají a fungují úplně stejně. Jedná se opět o tabulky s inline editací a formulářem pro přidání nového řádku ve spodní části. Jediné rozdíly jsou v popiscích a zobrazovaných datech. Na obrázku 2.12 si můžete prohlédnout stránku nastavení sortimentu. 27

40 2. Návrh uživatelského rozhraní Obrázek 2.9: Návrh stránky nastavení uživatelů Obrázek 2.10: Návrh stránky nastavení výkonů 28

41 2.5. Uživatelské rozhraní Obrázek 2.11: Návrh stránky nastavení organizačního dělení Obrázek 2.12: Návrh stránky nastavení sortimentu 29

42

43 Kapitola 3 Návrh architektury Z předchozí kapitoly víme, že uživatelské rozhraní bude realizováno jako webová aplikace. Také víme, jak bude zhruba vypadat a jakým způsobem bude probíhat jeho interakce s uživatelem. Před začátkem implementace je ještě třeba dopracovat celkovou architekturu systému. Zbývá rozhodnout zejména jakým způsobem bude uživatelské rozhraní (frontend) komunikovat s jádrem (backend) a kde bude umístěna (spouštěna) jeho logika. 3.1 Umístění frontend Kde bude spouštěn kód zodpovědný za vytvoření výsledného rozhraní? Na výběr je pouze ze dvou možností. Buď se bude vykonávat na serveru nebo u každého klienta v rámci webového prohlížeče. Na obrázku 3.1 si můžete prohlédnout náčrty obou řešení Frontend na serveru V prvním případě veškerou práci spojenou s templatováním, udržováním stavu rozhraní a formátováním dat pro backend provádí server. Do prohlížeče posílá už hotový HTML kód, který obsahuje i data. Výhody Využívá prostředky serveru, ne klienta. Rozhraní bude rychlejší při přístupu ze zařízení s malým výkonem. Lepší kompatibilita se zastaralými prohlížeči. Zobrazit HTML a odeslat formulář umí prohlížeče už dlouhou dobu. 31

44 3. Návrh architektury Obrázek 3.1: Možnosti umístění frontend Nevýhody Využívá prostředky serveru, ne klienta. Toto řešení bude pro stejný počet klientů vyžadovat větší výkon serveru. Větší náročnost na objem přenesených dat. Při každém dotazu se přenáší nejenom data, ale i celá HTML struktura. Akce uživatele nemají odezvu, dokud server nedokončí zpracování dotazu. To může v závislosti na rychlosti serveru a internetového připojení trvat znatelně dlouhou dobu Frontend u klienta Druhou možností je přesunout co nejvíce práce na klientské zařízení. Celý frontend v tomto případě poběží v rámci prohlížeče a ze serveru bude po prvotním načtení získávat pouze data. Výhody 32 Akce uživatele mají okamžitou odezvu.

45 3.2. Komunikace s backend Menší nároky na objem přenesených dat. Využívá prostředky klienta, nezatěžuje tolik server. Nevýhody Klade větší nároky na výkon klientského zařízení a jeho programovou výbavu (moderní prohlížeč) Výsledek Na základě předchozího porovnání jsem se rozhodl implementovat frontend jako webovou aplikaci běžící u klienta. Vedl mě k tomu zejména zvýšený uživatelský komfort při používání a menší nároky na objem přenesených dat. Tento přístup je sice náročnější na klientské zařízení, ale vzhledem k výkonu dnešních počítačů v tom nevidím problém. 3.2 Komunikace s backend Protože se frontend spouští na klientském počítači, musí komunikace s backend bez problémů fungovat v prostředí Internetu. Spolu s Jiřím Müllerem jsme se dohodli na řešení pomocí webové služby, která bude součástí backend a bude dodržovat základní principy REST[3]. Tento způsob je často používán 2 a oproti jiným řešením vyniká svou jednoduchostí, nízkou režií a možností snadno cachovat požadavky[29]. REST umožňuje v dotazech i odpovědích použít libovolně reprezentovaná data. Při komunikaci s frontend budou ale data kódována pomocí JSON. Toto řešení je zvoleno opět z důvodu jednoduchosti a malé režie. 2 Příklady REST rozhraní: [47] [5] [12] 33

46

47 Kapitola 4 Implementace 4.1 Výběr technologie Běh aplikací uvnitř prohlížeče umožňuje vícero technologií. Nejznámějšími z nich jsou JavaScript, Java, Adobe Flash a Microsoft Silverlight. Poslední tři jmenované ale nejsou v prohlížeči vždy dostupné. Pro svou funkci vyžadují nejrůznější pluginy, které se musejí nainstalovat zvlášť, nejsou dostupné na všech platformách a mohou vytvářet bezpečnostní mezery. Bezpečnost je také důvod, proč bývají tyto pluginy v defaultním nastavení vypnuté. Jako implemetační jazyk jsem z těchto důvodů zvolil JavaScript. Je dostupný téměř v každém prohlížeči a společně s HTML5 3 umožňuje bezproblémové spouštění komplexních webových aplikací. 4.2 MVC Při psaní udržovatelného a znovupoužitelného kódu nám může pomoci návrhový vzor Model-View-Controller. Jasné vymezení, za co je jaká část programu zodpovědná a jak se váže na další kusy aplikace, umožní snažší orientaci v programu a omezí zanášení chyb. MVC je vzor často používaný v server-side frameworcích jako je Nette, Spring, Zend a další. Používá se i v client-side JavaScriptových frameworcích a je doporučován pro vývoj webových aplikací [11]. 3 V současné době ještě není HTML5 standart dokončen. Přesto je jeho velká část již v prohlížečích implementována [34]. 35

48 4. Implementace 4.3 Framework Místo objevování kola se vyplatí postavit program nad již existujícími základy. Za tímto účelem vzniká i pro JavaScript mnoho frameworků. Mezi nejznámější z nich patří AngularJS[10], Backbone.js[17], Knockout[42], Ext.js[38] a Ember.js[45]. Po prostudování informací na internetových stránkách projektů a několika dalších zdrojů [2] [8] [39], jsem se rozhodl použít AngularJS. Vedla mě k tomu podpora dvousměrných datových vazeb, rozšiřitelná implementace templatování, množství hotových komponent [1], podpora dependency-injection a v neposlední řadě zastřešení projektu velkou firmou. 4.4 Další použité technologie Nginx Nginx[16] je HTTP server, reverzní proxy a mail proxy na kterém hostuji frontend. Kromě poskytování statických souborů ho také používám jako prostředníka pro přístup k backendu (viz 4.5.2) Yeoman Yeoman je nástroj pro webové vývojáře kombinující mnoho užitečných programů pod jednu střechu [33]. Umožňuje rychle vytvářet kostru aplikace, organizovat build proces a automaticky stahovat závislosti. V rámci sestavování umožňuje kompilovat Compass, kontrolovat kód na běžné chyby, spouštět unit testy, minifikovat js kód a mnoho dalších věcí. Mnou nejpoužívanější funkcí je livereload. Ta po zapnutí způsobí, že změny provedené ve zdrojovém kódu aplikace se okamžitě projeví v prohlížeči. V případě CSS dokonce bez refresh stránky Compass a SASS Compass, framework pro tvorbu CSS [6], zjednodušuje stylování zejména podporou pro tvorbu konzistentní typografie, používání experimentálních prefixovaných CSS3 pravidel a hromadné vytváření stylů pro ikony. Ve frontend pro LHE jsem z celého frameworku použil jen malou část týkající se CSS3. Spolu s Compassem jsem objevil a začal používat SASS, což je jazyk rozšiřující možnosti CSS [14]. Se SASS lze používat proměnné, dědičnost, vnořování pravidel a další funkce, které v CSS znatelně chybí. Soubor se zdrojo- 36

49 4.5. Úskalí vým kódem SASS se během sestavování aplikace zkompiluje do běžného CSS, kterému rozumí každý prohlížeč. Tento jazyk má dvě, funkčně ekvivalentí, varianty syntaxe. V projektu používám SCSS (Sassy CSS), která je novější a má blíže ke standartnímu CSS Twitter Bootstrap Twitter Bootstrap je frontend framework obsahující UI komponenty a předpřipravené styly. Umožňuje rychlé vytvoření aplikace, která od počátku vypadá rozumně. Ze všeho co nabízí používám hlavně scaffolding, což jsou styly pro tvorbu layoutu. Dále si v projektu můžete všimnout několika komponent jako je navbar a typeahead Font Awesome Jedná se o speciální font tvořený pouze ikonami. Výhodou tohoto řešení oproti obrázkům je možnost měnit velikost a barvu ikony pomocí CSS.[7] jquery jquery[44] je JavaScript knihovna usnadňující zejména manipulaci s DOM (Document Object Model) a práci s událostmi. Existuje pro ní velké množství plug-inů, které řeší nejrůznější problémy. Kromě vlastní knihovny používám v projektu také pluginy autogrow[20] a datepicker[43] ES5-shim Pro prohlížeče, které neimplementují vše ze standardu EcmaScript 5, je potřeba chybějící funkce doplnit. K tomu slouží es5-shim[24]. Posledním běžně používaným prohlížečem (podíl větší než 5%), který tento kód potřebuje, je Internet Explorer 8 [23] [41] CryptoJS CryptoJS[21] je implementace standardních kryptografických algoritmů v jazyce JavaScript. V LHE používám pouze funkce pro výpočet SHA Úskalí Při programování jsem narazil na mnoho problémů. Zde popisuji nejpodstatnější z nich a také to, jak jsem je vyřešil nebo obešel. 37

50 4. Implementace Bezpečnost Frontend LHE je spouštěn na počítači klienta. To, spolu s potřebou komunikovat s backend systému, vytváří potenciál pro bezpečnostní problémy. Prvním je samotná komunikace. Abych zabránil odchytávání a čtení komunikace po cestě Internetem, používám protokol HTTPS. Jedná se o rozšíření bežného HTTP o SSL/TLS. Při správném použití zabrání odposlechu, pozměňování dat i útokům typu man-in-the-middle. Aby nemohlo dojít ke krádeži identity, musí server používat certifikát vydaný klientem uznávanou certifikační autoritou. Z finančních důvodů jsem zvolil autoritu StartSSL, která vydává základní typ certifikátů zdarma [40]. Dalším problémem je autentizace uživatele proti backend. V tradičních systémech se přihlašovací údaje přenesou na server, který je ověří v databázi a stav přihlášení si pamatuje po dobu trvání session. Architektura systému LHE je ale navržena s bezstavovým komunikačním rozhraním. Na serveru tedy žádná session neexistuje a frontend musí posílat přihlašovací údaje v každém dotazu. Aby se minimalizovalo riziko s tím spojené, používá frontend místo hesla vygenerovaný token. Ten je vytvořen okamžitě po zadání potřebných údajů uživatelem a skládá se z uživatelského jména, hesla, aktuálního času (umožňuje omezit platnost tokenu) a několika statických textů. Tato data jsou zahashována algoritmem SHA256 a nadále používána k autentizaci místo hesla. Aby byl backend schopen ověřit pravost tokenu, posílá se v hlavičkách každého dotazu ještě uživatelské jméno a zmíněný timestamp také v nezahashované podobě Same-origin policy a CORS Pro komunikaci s backend používám JavaScriptový objekt XMLHttpRequest. Ten je z bezpečnostních důvodů omezen tak, aby umožnil vytváření spojení pouze na stejnou doménu,port a protokol jako je ten, ze kterého byl skript spuštěn (same-origin policy). To je pro systém LHE problém, protože frontend a backend jsou oddělené projekty, které používají rozdílné technologie a různé HTTP servery. Same-origin policy lze obejít pomocí techniky CORS (Cross-Origin Resource Sharing)[49]. Její použití spočívá v přidání speciálních HTTP hlaviček do odpovědí serveru. Z počátku jsem si myslel, že bude toto řešení funkční a dostatečné. Bohužel se ale ukázalo, že to není pravda. První problém CORS je, že pro složitější dotazy vyžaduje takzvaný preflight request. Takto si prohlížeč dopředu u serveru ověřuje, zda má svolení k odeslání onoho složitého dotazu. Výsledným efektem je zdvojnásobení latence. Druhý problém CORS je jeho problémová implementace v Internet 38

51 4.6. Výsledek Exploreru (IE). V určitých případech se během dotazu s použitím CORS ztratí response code a IE vrátí nulu [36]. Oba problémy jsem vyřešil nastavením reverzní proxy v nginx a posíláním veškerých dotazů přes ní. Po této úpravě jsou splněny podmínky same-origin policy a CORS tím pádem není pro produkční prostředí potřeba. Stále je to ale velmi užitečný nástroj pro vývoj a testování Kompatibilita prohlížečů Každý prohlížeč se bohužel chová trochu jinak. Nejvíce je tento problém patrný na méně používaných a relativně nových technologiích. S většinou prohlížečů jsem ale neměl problémy, které by zasáhly do funkčnosti aplikace. Nesrovnalosti se typicky omezovaly na interpretaci stylů a rychlost načítání stránky. Vyjímkou je ale Internet Explorer. Několikrát jsem musel vymýšlet obezličky, abych ho donutil ke spolupráci. Navíc se v něm aplikace špatně debuguje, protože jeho nástroje pro vývojáře jsou tragické. Například není možné zjistit, který z mnoha spouštěných skriptů vyvolal chybu. Víte, že chyba nastala. Máte její krátký popis. A to je vše. Tyto problémy působily spolu s chybou v implementaci CORS jako velká brzda při opravování chyb v IE. Funkčnost frontend jsem ověřoval v IE10,IE9, Chrome, Opeře a Firefoxu. Najít všechny chyby při zobrazování v IE8 se mi bohužel zatím nepodařilo a tak je v tomto prohlížeči frontend nefunkční. Pro testování v Internet Exploreru jsem používal několik virtuálních strojů, které Microsoft za tímto účelem zdarma poskytuje [28]. 4.6 Výsledek Z celého navrženého rozhraní jsem implementoval hospodářskou knihu, zadávání výkonů a většinu obrazovek nastavení. Pro dokončení projektu je třeba odvést mnoho další práce, což do termínu odevzdání určitě nestihnu. Hotové části aplikace ale spolu s backend systému tvoří funkční prototyp, na kterém je možné provést testování uživateli. 39

52

53 Kapitola 5 Testování použitelnosti Testování použitelnosti je kvalitativní forma uživatelského průzkumu. Metoda, kterou zde popisuji, nalézá chyby a slabé stránky rozhraní za pomoci pozorování uživatele při interakci s tímto rozhraním. 5.1 Kolikrát a kdy testovat? Nejlepší je provést co největší množství malých testů [19] a časově je rozložit do celé doby vývoje systému. Každý test je třeba vyhodnotit a co nejdříve opravit nalezené problémy. Tímto způsobem najdeme chyby brzy a tím ušetříme prostředky, které bychom jinak vložili do vývoje vadného rozhraní. 5.2 Na kolika lidech testovat? Pro dosažení co nejlepšího poměru cena/výkon se doporučuje omezit jedno testování přibližně na 5 lidí [26] [19] [22]. I s tímto počtem účastníků test běžně odhalí kolem 85% problémů a s novým nevyladěným rozhraním je toto procento ještě vyšší [22]. Je třeba si uvědomit, že tato čísla platí pouze v případě zaměření testování na zjišťování problémů a nikoli na získávání jakýchkoli statistických dat. 5.3 Koho testovat? Čím užší je zaměření produktu, tím důležitější je správně vybrat osoby pro jeho testování[26]. LHE je velmi specializovaný systém a tak je potřeba provádět testování na odbornících. 41