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 - backend Jiří Müller 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 Jiří Müller. 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 Müller, Jiří. IS pro lesní hospodářskou evidenci - backend. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.

7 Abstract The goal is to create an information system for forestry filling, which is required by law of Czech Republic. The thesis describes the process of creation of this system from initial analysis, through its implementation to testing. The result is functional application which in cooperation with frontend, allows management of forestry filling system. Keywords engineering forestry filling system, web services, REST, Java EE, software Abstrakt Tato práce si klade za cíl vytvořit informační systém pro lesní hospodářskou evidenci, jak ji vlastníkům lesa v České republice ukládá zákon. V práci je popsán celý proces vývoje od prvotní analýzy, přes implementaci až po testování. Výstupem praktické části práce je funkční aplikace umožňující ve spolupráci s frontend vedení lesní hospodářské evidenci. Klíčová slova Lesní hospodářská evidence, webové služby, REST, Java EE, softwarové inženýrství vii

8

9 Obsah Úvod 1 Motivace Struktura práce Analýza Analýza problematiky Existující řešení Případy užití Specifikace požadavků Návrh Architektura Výběr technologií Vybrané technologie podrobně API Webové služby Návrh tříd Architektura Návrh nasazení Implementace Použité nástroje Bezpečnost Architektura Reprezentace dat Testování Testování systému ix

10 Závěr 41 Literatura 43 A Seznam použitých zkratek 47 B Obrázky 49 C Obsah přiloženého CD 51 x

11 Seznam obrázků 1.1 LesIS Výroba PDS_ProPla Field-Map LHE Diagram tříd Diagram tříd Diagram nasazení Vrstvy aplikace Bez aspektu S aspektem B.1 Výrobně-mzdový lístek B.2 Use Case diagram xi

12

13 Seznam tabulek 2.1 API xiii

14

15 Úvod Motivace Firma Lesprojekt východní Čechy, s.r.o., zabývající se především tvorbou lesních hospodářských plánů, se rozhodla z důvodu zlepšení kontaktu se zákazníky, rozšířit portfolio nabízených služeb o systém pro lesní hospodářskou evidenci. Cílem této práce je vytvořit aplikaci pro lesní hospodářskou evidenci, která nebude trpě neduhy konkurenčních řešení a zároveň zjednoduší složitost nasazení na minimum. To bude v ideálním případě spočívat pouze v založení uživatelského účtu a nahrání dat Lesního hospodářského celku. Ač bude aplikace sdílená pro všechny uživatele, chtěl bych zachovat možnosti uživatelských úprav, které jsou běžně poskytovány v rámci implementace u zákazníka. Mojí hlavní motivací při tvorbě této práce je možnost vyzkoušet si tvorbu aplikace pomocí zajímavých technologií, jako je např. Java EE, která se v posledních letech prosazuje jako standard pro tvorbu robustní aplikací vhodných pro podnikové nasazení. Systém chci pojmout co nejčistěji z pohledu objektového návrhu, což by mělo umožnit snadnou údržbu a rozšiřování v budoucnu, kdy se počítá s rozšířením systému například o prohlížeč kartografických dat. 1

16 Úvod Struktura práce První kapitola zkoumá dostupné aplikace pro LHE a shrnuje jejich nedostatky, kterým se budu, při tvorbě IS, snažit vyhnout. Dále obsahuje kompletní analýzu pro systém. Druhá kapitola popisuje návrh aplikace na základě požadavků z kapitoly první. Ve třetí kapitole je popsán proces implementace. Poslední kapitola ukazuje testování implementované aplikace. 2

17 Kapitola 1 Analýza 1.1 Analýza problematiky Lesnictví je velmi specifický obor typický velkou setrvačností a konzervativností. Vyskytuje se v něm mnoho pojmů a postupů, které jsou pro člověka bez vzdělání v lesnictví neznámé, a proto je nutné provést důkladnou analýzu problematiky. V této části se ji pokusím nastínit a vysvětlit dále používané pojmy. Tyto informace byly získány prostřednictvím Petra Gregora, který je zjistil přímo od zástupců zadavatele nebo při komunikaci s budoucími uživateli systému Struktura lesa Nejvyšší správní jednotkou lesa je Lesní hospodářský celek (LHC). Rozdělení LHC na menší celky upravuje vyhláška č.84/96 Sb. Ministerstva zemědělství ze dne 18. března 1996 o lesním hospodářském plánování [27], jejíž 6 článek 3 stanoví, že: Jednotkami prostorového rozdělení lesa jsou: oddělení, dílec, porost, porostní skupina a etáž, přičemž porost je základní jednotkou tohoto rozdělení, která musí být vždy vylišena. Následuje stručný popis jednotek: LHC Celek s jedním vlastníkem o maximální rozloze ha. Označuje se číslem např Oddělení Maximální výměra 150 ha. Označení číslem. 3

18 1. Analýza Dílec Maximální výměra 50 ha. Označení velkým písmenem. Porost Značení malým písmenem. Porostní skupina Spojitá část lesa, která se shoduje ve věku a druhové skladbě. Obsahuje minimálně jednu etáž. Etáž Etáže rozlišují jednotlivá patra lesa. Označují se stejně jako porostní skupiny. Pokud porostní skupina obsahuje více etáží, je její označení složeno z názvů etáží oddělených lomítkem Lesní hospodářský plán Jednou za 10 let vypracuje specializovaná firma pro LHC nový Lesní hospodářský plán (LHP). Ten obsahuje s přesností na etáže jednak kompletní inventuru lesa, tj. co kde roste, jak starý je porost, jaký je jeho stav apod., a jednak návrh zásahů, které by se měly v následujících 10-ti letech v lese vykonat. Tyto informace jsou zaznamenané v tzv. Hospodářské knize. Data pro hospodářskou knihu jsou dostupná v digitální formě ve formátu XML podrobně specifikovaném informačním standardem lesního hospodářství [26] Lesní hospodářská evidence Z 40 lesního zákona [17] vyplývá pro vlastníky lesa povinnost vést lesní hospodářskou evidenci (LHE). Tato evidence obsahuje především záznamy o plnění závazných ustanovení plynoucích z lesního hospodářského plánu a evidenci obnovy lesa. Souhrná data z LHE jsou každoročně předávána orgánům státní zprávy a slouží jako výkaz o průběžném plnění lesního hospodářského plánu. 1.2 Existující řešení Lesy tvořily v roce 2011 dle [9] asi 33.73% rozlohy České republiky a tak není divu, že se lesní hospodářskou evidencí zabývá mnoho aplikací. Uveďme několik nejvýznamnějších: LesIS LesIS [15] je komplexní software pro správu lesnického provozu. Je tvořen zakázkově. Od roku 2009 ho využívá Správa NP a CHKO Šumava, pro které byl také primárně vyvinut. 4

19 1.2. Existující řešení Výhody: Komplexní řešení Obsahuje také mobilní řešení na platformě Android Nevýhody: Vysoká cena - základní instalace dle [14] stojí 1,5 mil Kč bez DPH a implementace u zákazníka dalších 500 tis. Kč bez DPH Nutnost nasazení u zákazníka - není poskytováno jako služba Potřeba vlastního HW a z toho plynoucí nutnost údržby Obrázek 1.1: LesIS Výroba 3000 Celým jménem Lesní a hospodářská evidence Výroba 3000 [10] je desktopová aplikace pro OS Windows. Byla vyvinuta firmou IterSoft s.r.o. 5

20 1. Analýza Výhody: Obsahuje prohlížečku hospodářských knih a mapových dat vyhovujících standardu pro lesní hospodářství[26] Zvládá exporty do mzdových a účetních programů Nevýhody: Pouze desktopová aplikace, z čehož plyne nutnost instalace Obrázek 1.2: Výroba PDS_ProPla Komplexní nástroj pro lesní hospodářství[21], který mimo jiné umožňuje i vedení LHE. Byl vyvinut ve firmě PDS, s.r.o., která se zaměřuje na tvorbu informačních systémů pro lesnictví, zemědělství, životní prostředí, státní správu. Mezi největší organizace využívající PDS_ProPla patří Lesy ČR a Vojenské lesy a statky ČR 6

21 1.2. Existující řešení Výhody: Obsahuje prohlížečku mapových dat Tvorba projektů těžebních a pěstebních prací Nevýhody: Opět pouze desktopová aplikace pro OS Windows Obrázek 1.3: PDS_ProPla Field-Map LHE Field-Map LHE [7] je systém pro vedení LHE od firmy IFER, který umožňuje provoz jak na jednom počítači tak síťově. Výrobce uvádí, že je jej možné modifikovat přímo podle potřeb konkrétního zákazníka. Výhody: Oboustranná synchronizace dat s centrální databází 7

22 1. Analýza Mapová část obsahuje pokročilé editační funkce Možnost připojit GPS Nevýhody: Opět pouze desktopová aplikace pro OS Windows Obrázek 1.4: Field-Map LHE 1.3 Případy užití Případy užití popisují množinu akcí, které je možné vykonávat v prostředí systému. Jsou popisovány z pohledu zadavatele pomocí běžného jazyka a za pomoci pojmů z problémové domény. Byly identifikovány tři uživatelské role: Administrátor, Vlastník lesa, Pracovník. Nejvíce oprávnění má Administrátor, který může provádět všechny akce související se správou 8

23 1.3. Případy užití systému. Podmnožinu těchto akcí obohacenou o akce související se Zásahy, Sortimentem, Výrobky a Odběrateli může vykonávat Vlastník lesa, ale je omezen na vlastní LHC. Vlastník může některé akce delegovat na jím definované Pracovníky. Některé akce (jako např. Vykázání prodeje dřeva) může vykonávat více rolí. Takovéto akce jsou v následujícím přehledu zařazeny pouze k roli, pro kterou jsou typičtější. Všechny případy užití znázorňuje diagram B.2. Administrátor Role Administrátor bude náležet uživateli určenému ke správě celého systému. Tento uživatel bude především vytvářet vlastníky lesa a řešit problémy uživatelů se systémem. UC1: Správa uživatelů Popis: Přidá, upraví popř. odstraní uživatele podle zadaných parametrů. UC2: Import dat z LHP Popis: Přidá do systému nové LHC Vlastník lesa Vlastník lesa je uživatel, který může po přihlášení do systému, importovat LHC a upravovat jeho nastavení. Mezi běžnou činnost vlastníka lesa bude patřit vytváření pracovníků, schvalování jejich výkazů, tvorba a získávání dat podle parametrů. UC3: Zobrazení dat podle parametrů Popis: Podle zadaných parametrů získá data a zobrazí výsledek. UC4: Schválení zásahu 9

24 1. Analýza Popis: Schválí vybraný zásah. Zásah přechází ze stavu Neschválený do Schválený UC5: Správa uživatelských číselníků Popis: Umožní upravovat uživatelské číselníky UC6: Správa pracovníků Popis: Umožní vytvářet, mazat a upravovat účty pracovníků. UC7: Úprava práv pracovníků Popis: Umožní přiřazovat pracovníkům střediska a oprávnění v nich. Pracovník Pracovník je role s nejomezenějšími právy. Může pouze vykazovat zásahy, prodeje dřeva a procházet hospodářskou knihu, ale pouze ve střediscích, ve kterých k tomu má oprávnění. UC8: Procházení hospodářské knihy Popis: Systém zobrazí všechny informace z LHP o aktuálně vybrané jednotce. UC9: Úprava osobní údajů Popis: Umožňuje uživateli upravit údaje o vlastní osobě a údaje pro přihlášení. 10 UC10: Vykázání zásahu

25 1.4. Specifikace požadavků Popis: Umožňuje vytvoření nového zásahu. Zásah je vytvořen ve stavu Neschválený. UC11: Vykázání prodeje dřeva Popis: Umožňuje vytvoření nového prodeje dřeva. Prodej je vytvořen ve stavu Neschválený. 1.4 Specifikace požadavků Specifikace požadavků je dokument, který popisuje úplné chování vyvíjeného systému[32]. Požadavky musí splňovat několik podmínek: musí být proveditelný, měřitelný, testovatelný, a musí být definovaný dostatečné detailně pro účely návrhu systému. Požadavky se dají rozdělit na funkční a nefunkční. První jmenované popisují konkrétní funkce, které musí systém podporovat a druhé (někdy označované také jako doplňkové) definují omezení kladená na design a provedení. Mezi nefunkční patří požadavky na výkonnost, spolehlivost nebo rychlost odezvy. Musí být přesně specifikované aby nedocházelo k nejasnostem. Typicky špatně definovaný požadavek zní: Systém bude výkonný. Takovýto požadavek není možné ověřit ani otestovat a proto se nesmí ve specifikaci objevit. Správně formulovaný nefunkční požadavek by mohl zní: Systém dokáže za sekundu obsloužit 10 dotazů. Sběr požadavků na celý systém u zadavatele provedl Petr Gregor ve své bakalářské práci[5]. Na základě nich jsem specifikovali požadavky kladené na backend systému Funkční požadavky S Petrem Gregorem jsem společně sestavili seznam požadavků kladených ze strany JS klienta na webovou službu. Následující tabulka zachycuje jednotlivé požadavky a jejich vlastnosti Hospodářská kniha F1: Import LHC do systému 11

26 1. Analýza Popis: Přidá do systému nové LHC a importuje jeho strukturu a LHP. Nahrané LHC se přiřadí vlastníkovi, který ho může následně začít spravovat. F2: Získání všech LHC Popis: Slouží pro výpis všech LHC v systému pro Administrátora. F3: Získání LHC Popis: Vrátí informace o jednom konkrétním LHC. F4: Získání struktury celého LHC Popis: Vrátí strukturu celého LHC. Kořenem struktury je LHC, územní jednotky tvoří strom a jsou reprezentovány pomocí párů ID a NÁZEV. F5: Získání oddělení jednoho LHC Popis: Slouží pro výpis oddělení spadajících do jednoho LHC. F6: Získání oddělení Popis: Vrátí informace o jednom konkrétním Oddělení 12

27 1.4. Specifikace požadavků F7: Získání dílců jednoho oddělení Popis: Slouží pro výpis dílců spadajících do jednoho oddělení. F8: Získání dílce Popis: Vrátí informace o jednom konkrétním dílci. F9: Získání porostů jednoho dílce Popis: Slouží pro výpis porostů spadajících do jednoho dílce. F10: Získání porostu Popis: Vrátí informace o jednom konkrétním porostu. F11: Získání por. skupin jednoho porostu Popis: Slouží pro výpis porostních skupin jednoho porostu. F12: Získání porostní skupiny Popis: Vrátí informace o jedné porostní skupině. F13: Získání etáží jedné por. skupiny Popis: Vrátí etáže v porostní skupině. 13

28 1. Analýza F14: Získání etáže Popis: Vrátí kompletní informace o jedné etáži Nastavení LHC F15: Vytvoření/úprava střediska Popis: Vytvoří v LHC nové středisko, popř. upraví stávající. Do střediska může spadat více porostů. Těmi je v tomto případě myšlena libovolná územní jednotka od oddělení po porostní skupinu. F16: Odstranění střediska Popis: Odstraní středisko se všemi porosty. F17: Získání středisek podle LHC Popis: Vrátí seznam všech středisek v LHC a také jaké porosty do nich patří. F18: Vytvoření/úprava odběratele Popis: Vytvoří nového odběratele, popř. upraví stávajícího. Odběratel má jméno, adresu a kontaktní telefon. F19: Odstranění odběratele Popis: Odstraní odběratele. 14

29 1.4. Specifikace požadavků F20: Získání odběratelů podle LHC Popis: Vrátí seznam všech odběratelů evidovaných v LHC F21: Vytvoření/úprava výrobku Popis: Vytvoří nebo upraví Výrobek v LHC F22: Odstranění výrobku Popis: Odstraní výrobek z LHC F23: Získání výrobků podle LHC Popis: Slouží pro výpis všech výrobků definovaných v LHC F24: Vytvoření/úprava sortimentu Popis: Vytvoří nebo upraví Sortiment v LHC F25: Odstranění sortimentu Popis: Odstraní Sortiment z LHC F26: Získání sortimentu podle LHC Popis: Slouží k zobrazení všech výrobků definovaných v konkrétním LHC 15

30 1. Analýza F27: Vytvoření/úprava výkonu Popis: Vytvoří nebo upraví Výkon v LHC. Výkon může obsahovat Podvýkony. F28: Odstranění výkonu Popis: Odstraní Výkon z LHC. Všechny Podvýkony spadající pod Výkon budou odstraněny také Výroba F29: Vytvoření/úprava zásahu Popis: Vytvoří nebo upraví Zásah. Slouží také ke schvalování Zásahů. F30: Získání zásahů podle LHC Popis: Zobrazí všechny výkony v daném LHC. F31: Získání zásahů podle data Popis: Zobrazí výkony provedený v daném časovém intervalu. F32: Získání zásahů podle Etáže Popis: Zobrazí výkony provedené v dané etáži. 16

31 1.4. Specifikace požadavků F33: Odstranění zásahu Popis: Odstraní zásah ze systému Ostatní F34: Vytvoření/úprava uživatele Popis: Vytvoří v systému nového uživatele, nebo upraví stávajícího. F35: Odstranění uživatele Popis: Odstraní uživatele ze systému. F36: Získání aktuálního uživatele Popis: Získá data o právě přihlášeném uživateli. F37: Získání všech uživatelů Popis: Slouží pro Administrátora. Zobrazí seznam všech uživatelů v systému. F38: Získání časových jednotek Popis: Zobrazí všechny jednotky času definované v systému. 17

32 1. Analýza F39: Získání plošných jednotek Popis: Zobrazí všechny jednotky plochy definované v systému. F40: Získání množstevních jednotek Popis: Zobrazí všechny jednotky množství definované v systému. F41: Získání aktuálního času Popis: Zobrazí aktuální systémový čas. Slouží k synchronizaci času mezi klientem a serverem při výpočtu přihlašovacího tokenu Nefunkční požadavky N1: Formát importu Popis: Systém musí umět importovat data ve formátu informačního standardu lesního hospodářství[26] N2: Běhové prostředí Popis: Systém musí být kompatibilní s platformou Xen Cloud Platform N3: Nároky na hardware Popis: Systém musí být schopen běžet na serveru s 3.5GB RAM, který pro něj bude vyhrazen. 18

33 Kapitola 2 Návrh 2.1 Architektura Vzhledem k tomu, že aplikace bude vyvíjena v rámci dvou závěrečných prací, rozhodli jsem se, že ji rozdělíme na dvě součásti a to: 1. Webová služba 2. Uživatelské rozhraní v HTML a JS Tato architektura má několik výhod. Mezi hlavní bych zařadil možnost téměř nezávislého vývoje backendu a frontendu, kdy stačí, aby bylo společně navrženo pouze aplikační rozhraní webové služby. To se v případě RESTových služeb dělá pomocí XML souboru ve formátu WADL, který popisuje jaké metody webová služba poskytuje, jaké jsou jejich parametry a jaké návratové hodnoty. Dalším přínosem je minimalizace přenášených dat, protože uživatelské rozhraní se načte pouze jednou a pokud uživatel požaduje změnu pohledu, provede klient pouze ajaxový dotaz na server a jeho výsledek zobrazí. To by se mělo pozitivně promítnout na rychlosti práce se systémem a také na malých nárocích kladených na server, který by měl být schopen obsluhovat více klientů připojených naráz, než kdyby pokaždé odesílal kompletní pohled Webová služba Webová služba je aplikace uzpůsobená k tomu, aby ji používaly jiné aplikace. Není určena pro přímý přístup uživatelů. Webové služby se dělí na dvě hlavní skupiny podle používaného protokolu: 19

34 2. Návrh 1. SOAP[29] Simple Object Access Protocol je protokol založený na vystavování aplikační logiky jako služby. Typicky používá zprávy založené na XML k provádění akcí. Je nástupcem XML-RPC. 2. REST[33] Neboli Representational State Transfer je protokol orientovaný na vystavování zdrojů (resources). Každý zdroj je identifikovaný unikátním identifikátorem a URL. Používá se obvykle pokud webová služba bude poskytovat převážně CRUD operace. K tomu se používají metody protokolu HTTP: Operace HTTP Metoda Příklad URL Create POST /article Read GET /article/3 Update PUT /article/3 Delete DELETE /article/3 Pro náš informační systém jsme zvolili REST a to především z důvodu převahy CRUD operací nad ostatní logikou Formát zpráv RESTová webová služba může pro přenos dat použít celou řadu formátů, nejvíce se ale používá XML a JSON. XML Neboli Extensible Markup Language[28] je standardizovaný značkovací jazyk. Mezi jeho výhody patří velké rozšíření a tím pádem i výborná podpora ve většině programovacích jazyků. Ve srovnání s jazykem JSON je o něco více datově náročný. JSON JavaScript Object Notation[8] je odlehčený formát pro výměnu dat, založený na podmnožině jazyka JavaScript. Je stejně jako XML velmi dobře podporován programovacími jazyky a navíc je možné ho v moderních prohlížečích nativně parsovat. To má velký vliv na rychlost jeho zpracování. Nakonec jsme pro implementaci komunikace zvolili JSON, hlavně kvůli jednoduchosti a rychlosti parsování na straně klienta, protože předpokládáme zpracovávání velkého množství dat v klientském prohlížeči, což by se mohlo v případě použití XML podepsat na pomalých odezvách a zbytečném přetěžování klientských PC. 20

35 2.2. Výběr technologií Nicméně služba bude schopná poskytovat data i ve formátu XML, což se bude hodit v budoucnu pokud by byl vyvíjen klient, pro který bude XML vhodnější. To zda bude vstup a výstup v JSON nebo XML se určí během tzv. Content negotiation, kdy klient formát dat vybere pomocí HTTP hlaviček Content-Type a Accept, které mohou nabývat hodnot application/json pro JSON a analogicky application/xml pro XML. 2.2 Výběr technologií Výběr správných technologií pro implementaci bývá často klíčový pro úspěch softwarového projektu. Pojem technologie v tomto případě znamená především programovací jazyky, ekosystémy těchto jazyků a podpůrné frameworky. Technologie jsem hodnotil podle několika kritérií: 1. Podpora webových služeb - Podle mě asi nejdůležitější z kritérií. Alfou a omegou systému bude převod dat do JSONu a zpět. Technologie musí dobře zvládat mapování URL a HTTP metod na konkrétní metody služby. 2. Znalost technologie - Další důležité kritérium. V ideálním případě bude zvolena technologie, se kterou mám určité zkušenosti. Toto kritérium je ovšem dvojsečné. Může svádět k výběru pouze z mých oblíbený technologií a diskvalifikovat prvotřídní nástroje šité na míru potřebám projektu. Avšak obvykle zabraňuje fatálním přehmatům, kdy je zvolena technologie, která sice na první pohled splňuje všechny požadavky, ale v polovině implementace se zjistí problém, který je s vybranou technologií neřešitelný. Znalost technologie také výrazně urychluje samotnou implementaci, protože se vývojář nemusí učit od základů například nový jazyk. 3. Výkon - Systém může být ve špičce zatěžován velkým množstvím dotazů, a proto by bylo vhodné, aby nespotřebovával moc prostředků. Do této kategorie spadají i možnosti cachování a škálovatelnosti. 4. Rozšířenost a dokumentace - Hodnotí technologii z pohledu dokumentace a také jaké je její rozšíření a dostupnost programátorů. Systém musí být udržovatelný i v případě, že v práci na něm nebudu dále pokračovat. Toto kritérium diskvalifikuje obskurní jazyky, pro které je prakticky nemožné při rozumných nákladech získat programátory. 21

36 2. Návrh PHP Oblíbený interpretovaný jazyk, který vyniká jednoduchostí a snadností učení. Podle [30] je podíl PHP mezi serverovými programovacími jazyky pro web drtivých 79.4%. PHP má obrovskou komunitu a výbornou dokumentaci. Mezi nevýhody PHP patří především historické dědictví ve formě ne zcela dotažené podpory pro objektově-orientované programování a náchylnost na určitý druh chyb (kvůli dynamickému typování). Ač má PHP velký tržní podíl, není příliš rozšířené mezi aplikacemi s velkým provozem[31]. Samotné PHP se v současnosti příliš nepoužívá, aktuálním trendem je kombinace s nějakým frameworkem, který usnadňuje běžné úkony. Mezi, podle mého názoru, nejzajímavější frameworky patří český Nette Framework[19] od Davida Grudla. Mezi jeho největší přednosti patří výborná podpora formulářů a šablonování pomocí vlastního šablonovacího jazyka Latte. Nette se hodí pro vývoj klasických webových stránek, ale na tvorbu webových služeb není uzpůsoben. Firma Zend, která stojí za vývojem PHP, představila vlastní Zend framework[35] jehož součástí je komponenta Zend_Rest, která přináší podporu RESTových webových služeb. Ta se bohužel omezuje pouze na mapování funkcí na URL a už nijak neřeší například převod objektů do JSONu a zpět. Po stránce výkonu na tom není PHP moc dobře, ale tento problém je řešitelný například pomocí projektu HipHop [4] vyvinutého ve Facebooku, který PHP kompiluje do C++ a tak urychluje jeho provádění Java EE Pokud je PHP standardem pro malé webové stránky, tak pro ty velké je to Java. Moderní multiplatformní jazyk, oblíbený v podnikové sféře pro svou bezpečnost 1 a rychlost vývoje. Pro vývoj webových služeb nabízí framework JAX-RS [12], který umožňuje přímé namapování URL na metodu a velmi propracovaný převod objektů na XML/JSON pomocí JAXB. Pro Javu dále hovoří dobrá podpora objektově-relačního mapování, které často velmi usnadňuje vývoj. Java nikdy nevynikala rychlostí, ale situace se výrazně zlepšila po příchodu JIT (Just-in-time), kdy není interpretován bytekód, ale aktuální kódový segment se přeloží do strojového kódu a až ten je následně prováděn. 1 Ve srovnání s ostatními jazyky. 22

37 2.3. Vybrané technologie podrobně Ruby on Rails Tento framework v jazyce Ruby nabízí určitou podporu webových služeb, ale není dostupná kvalitní dokumentace a vývojářská komunita se řadí mezi ty menší. Nutno podotknout, že s Rails nemám žádné zkušenosti, a proto by se vývoj mohl protáhnout na příliš dlouhou dobu, což by znemožnilo včasné předání hotového projektu zadavateli. 2.3 Vybrané technologie podrobně Volba nakonec padla na Enterprise Javu a framework JAX-RS. Vybral jsem je z několika důvodů: 1. Snadný převod objektů do JSON a XML 2. Mám zkušenosti s vývojem v Javě 3. Využívaná technologie v Enterprise sféře 4. Dostupná kvalitní vývojová prostředí JAX-RS JAX-RS neboli Java API for RESTful Web Services je aplikační rozhraní v jazyce Java, které poskytuje podporu pro tvorbu RESTových webových služeb. Je postaveno na anotacích, které umožňují mapování objektů na zdroje webové služby JAXB Java Architecture for XML Binding umožňuje převod objektů na JSON/XML. Objekty se převádějí rekurzivně tzn. je nutno zabránit zacyklení. Za účelem úpravy výchozího chování obsahuje JAXB mnoho anotací, které upravují marshalling 2. Uveďme několik Označuje třídu, kterou je možné Upřesňuje, zda budou k přístupu k členským proměnným použity gettery a Takto anotovaná proměnná nebude převáděna. Typicky slouží k zamezení zacyklení a odstranění nepotřebných dat. 2 Převod objektu na jinou reprezentaci. Proces podobný serializaci. 23

38 2. Proměnná bude převedena do XML jako atribut. Možné použít pouze pro primitivní typy. V JSONu se neprojeví MySQL Open-source relační databázový stroj aktuálně ve verzi 5.6. Nabízí většinu funkcí moderních databází jako např. transakce, triggery a umožňuje clustering Java Persistance API Rozhraní pro persistenci dat v jazyce java. Pro práci s ním se používá objekt EntityManageru, který obstarává ukládání, vyhledávání a mazání objektů z databáze. Java Persistance API má mnoho implementací, v našem projektu využijeme EclipseLink [3]. Alternativně je možno použít také např. Hibernate[13] Glassfish Glassfish[20] je open-source aplikační server pro platformu Java EE. Je vyvíjen společností Oracle Corporation a slouží jako referenční implementace, což zajišťuje podporu technologií jako např. Enterprise JavaBeans, JPA, JavaServer Faces, JMS, RMI nebo JavaServer Pages. 24

39 2.4. API Webové služby 2.4 API Webové služby API neboli Application Programming Interface, někdy je také v kontextu webových služeb nazýváno Web API [34]. Označuje rozhraní, prostřednictvím kterého aplikace zpřístupňuje některé své funkce jiným aplikacím. V našem případě popisuje způsob, jakým bude backend systému komunikovat s frontendem běžícím v klientském webovém prohlížeči. API bylo ve spolupráci s Petrem Gregorem sestaveno na základě funkčních požadavků. Ke každému z nich bylo přiřazeno URL, HTTP metoda a definováno, jaká data musí obsahovat požadavek a jaká bude odpověď vrácená serverem. Takto vzniklo mapování 1:1 mezi API a požadavky, což zajistí, že budou všechny splněny a na žádný se nezapomene. Protože je v tomto okamžiku jasná struktura komunikace je možné začít psát testy (viz kapitola 4). URL byla přiřazena tak, aby operace s jedním druhem objektů byly sdruženy na URL se společným kořenem. Například nový uživatel se vytváří přes stejnou URL jako se získává seznam všech uživatelů user/ a odstraňuje se přes user/{id}. Přiřazení HTTP metod respektuje zaběhnuté zvyklosti RESTu [23]. Zdroje a kolekce se získávají pomocí GET. Vytvářejí popř. upravují se metodami PUT a POST a konečně mazání probíhá přes DELETE. Při vytváření nového zdroje je obvykle potřeba rovnou zjistit, jak (typicky s jakým ID) byl vytvořen. Proto server vždy po vytvoření odesílá nový objekt zpět, aby bylo možné vyčíst jeho ID a dále s ním pracovat. Výsledné rozhraní je zobrazeno v tabulce Názvy typů vychází ze specifikace ministerstva zemědělství [26] 25

40 2. Návrh # URL Metoda Vstupní data Výstupní data F1 dataislh/ POST DATAISLH F2 lhc/ GET Kolekce LHC F3 lhc/{id} GET LHC F4 lhc/{id}/struktura GET Struktura objektů F5 lhc/{id}/oddeleni GET Kolekce ODD F6 odd/{id} GET ODD F7 odd/{id}/dilce GET Kolekce DIL F8 dil/{id} GET DIL F9 dil/{id}/porosty GET Kolekce POR F10 por/{id} GET POR F11 por/{id}/porostniskupiny GET Kolekce PSK F12 psk/{id} GET PSK F13 psk/{id}/etaze GET Kolekce ETZ F14 etz/{id} GET ETZ F15 stredisko/ PUT Stredisko Stredisko F16 stredisko/{id} DELETE F17 stredisko/lhc/{id} GET Kolekce Středisek F18 odberatel/ PUT Odberatel Odberatel F19 odberatel/{id} DELETE F20 odberatel/lhc/{id} GET Kolekce Odběratelů F21 vyrobek/ PUT Vyrobek Vyrobek F22 vyrobek/{id} DELETE F23 vyrobek/lhc/{id} GET Kolekce Výrobků F24 sortiment/ PUT Sortiment Sortiment F25 sortiment/{id} DELETE F26 sortiment/lhc/{id} GET Kolekce Sortimentu F27 vykon/ PUT Vykon Vykon F28 vykon/{id} DELETE F29 zasah/ PUT Zasah Zasah F30 zasah/lhc/{id} GET Kolekce Zásahů F31 zasah/od/{od}/do/{do} GET Kolekce Zásahů F32 zasah/etaz/{id} GET Kolekce Zásahů F33 zasah/{id} DELETE F34 user/ PUT User User F35 user/{id} DELETE F36 user/current GET User F37 user/ GET Kolekce User F38 jednotka/cas GET Kolekce Jednotek F39 jednotka/plocha GET Kolekce Jednotek F40 jednotka/mnozstvi GET Kolekce Jednotek F41 utils/time GET Časové razítko 26 Tabulka 2.1: API

41 2.5. Návrh tříd 2.5 Návrh tříd Služba Návrh tříd, které budou obsluhovat požadavky na službu, vychází z navrženého API. Metody, které mají stejnou kořenovou URL jsou vždy seskupeny do jedné třídy. Všechny takto vzniklé třídy mají společného předka Abstract- Facade, ve kterém jsou definovány společné metody a který má referenci na EntityManager, který bude zajišťovat persistenci dat. Výjimku tvoří třída UtilsFacadeREST, která EntityManager nepotřebuje a tím pádem dědí pouze z java.lang.object. Obrázek 2.1: Diagram tříd 27

42 2. Návrh 2.6 Architektura Datový model Vzhledem k tomu, že systém bude muset pracovat s daty ve formátu podle Informačního standardu Ministerstva zemědělství [26] můžeme pro základ datového modelu použít XDS šablonu tohoto standardu, která definuje jakou strukturu má LHC a jaká data může obsahovat LHP. Aby nebylo potřeba přepisovat celou šablonu do tříd v jazyka Java, použijeme JAXB Binding Compiler - xjc[22], který dokáže s XSD šablony vytvořit vhodné třídy a navíc je oanotuje pomocí JAXB anotací a tím umožní převod dat ve formátu JSON do Java objektů a zpět. Schéma je ovšem nutno silně upravit, protože JAXB má tendenci některé atributy převádět nevhodně a spojovat jich více do jedné členské proměnné. To poté vede k tomu, že se několik vlastností do databáze ukládá jako jeden BLOB. Výsledné schéma je ekvivalentní s lesním hospodářským standardem [26] a proto ho nebudu dále popisovat. Toto schéma je obohaceno o třídy, pracovně nazvané jako Výroba a Nastavení. Relevantní část schématu je zobrazena na obrázku 2.2. Zjednodušeně řečeno ke každému LHC jsou přiřazeny výkony a podvýkony, které je v něm možné vykonávat, výrobky a sortiment, které se zde vytváří nebo spotřebovává, a dodavatelé, se kterými se spolupracuje. Výkony a podvýkony mají stejné atributy a ty jsou proto vyčleněny do abstraktního předka AbstrVykon. Pokud je v lese proveden nějaký výkon, je vytvořen zásah, který obsahuje kompletní informace o provedené činnosti, tj. druh výkonu a podvýkonu, množství, čas, plochu a také etáž, ve které se činnost odehrála. Dále může obsahovat informace o sortimentu a výrobcích. Za účelem dělení LHC do menších celků, které budou přiřazovány pracovníkům, existují entity Středisko a Porost. Středisko může obsahovat více revírů. Ty zase obsahují libovolnou část LHC, tedy oddělení, dílec, porost nebo porostní skupinu. Model dále obsahuje několik pomocných entit např. pro správu uživatelů, které jsou ovšem z pohledu návrhu nezajímavé a proto je nebudu podrobně uvádět. 28

43 2.6. Architektura Obrázek 2.2: Diagram tříd 29

44 2. Návrh 2.7 Návrh nasazení Informační systém bude nasazen na virtualizovaném serveru s OS Ubuntu na aplikačním serveru Glassfish. Na stejném serveru poběží web-server Nginx, který bude klientům zpřístupňovat frontend. Backend bude vystavovat RESTovou webovou službu prostřednictvím níž s ním bude komunikovat frontend. Pro ukládání dat bude backend používat databázový stroj MySQL. Obrázek 2.3: Diagram nasazení 30

45 Kapitola 3 Implementace 3.1 Použité nástroje Při implementaci jsem používal především integrované vývojové prostředí NetBeans[18], které vyniká výbornou podporou aplikačního serveru Glassfish[20] a umožňuje na jedno kliknutí rychlé nasazení aplikace. Pro simulaci požadavků na server jsem využil nástroj curl[6], ve kterém lze jednoduše nastavit všechny parametry požadavku od hlaviček až po posílaná data a také následně analyzovat odpověď ze serveru. Pro kreslení diagramů v této práci jsem použil ArgoUML[25] a Astah[1]. 3.2 Bezpečnost V současnosti je bezpečnost webových aplikací často skloňovaným pojmem. Skoro každý den je možné se dočíst, že došlo k napadení nějakého systému nebo úniku důležitých dat. Podle Web Application Vulnerability Statistics of 2012 [11] obsahuje průměrně velká webová aplikace 35 (!) zranitelností. Při implementaci jsem se snažil všech bezpečnostních chyb vyvarovat, ale jak se stále častěji ukazuje, napadnutelný je každý systém. Zabezpečení je implementováno na několika úrovních: Zabezpečení komunikace Veškerá komunikace probíhá pomocí protokolu HTTPS, kdy je komunikace šifrována pomocí SSL/TLS, což zabraňuje odposlechu např. přihlašovacích údajů. Server je vybaven vlastním certifikátem, aby útočník nemohl ukrást identitu systému. 31

46 3. Implementace Zabezpečení na úrovni jazyka Architektura Javy zabraňuje napsání programu, který by destruoval samotnou Java Virtual Machine. Veškerý spuštěný bytekód prochází verifikací a pro přístup k chráněným prostředkům je nutné, aby měl kód příslušné povolení Autentizace uživatelů Autentizace je proces ověření identity uživatele. Vzhledem k tomu, že RESTová služba je navržena jako kompletně bezstavová, je nutné provádět autentizaci uživatelů s každým požadavkem znovu a ne jen jednou na začátku komunikace a dále ověřovat uživatele pomocí cookies jako je to obvyklé u jiných aplikací. Zvolili jsem postup posílání autentizačních údajů v hlavičce požadavku, kdy mimo jiné obsahuje tyto údaje: LHE_username - uživatelské jméno uživatele, LHE_hash - sha256 hash. Jako poslední se posílá také LHE_timestamp, který obsahuje čas vytvoření hashe. Když server přijme požadavek, jako první zkontroluje LHE_timestamp, který nesmí být starší než 14 dní. Následně se pokusí najít uživatele v databázi podle uživatelského jména, pokud není nalezen, je požadavek odmítnut. Pokud ano, je spočítán hash z uživatelského jména, hashe hesla, času z hlavičky LHE_timestamp a statické soli. Výsledný hash je porovnán s hodnotou LHE_hash. Pokud je shodná, je uživatel autentizován Autorizace Autorizace je proces, při kterém se určuje, zda je uživatel oprávněn k vykonání nějaké akce. Za tímto účelem je každému uživateli přiřazena skupina. Majitelé lesa mají navíc vazbu na LHC a pracovníci vazbu N:M na Středisko. Pokud je uživatel ve skupině administrátor, neprobíhá žádné ověřování a požadavek je rovnou obsloužen. V případě, že se jedná o majitele lesa, je pouze ověřeno, že přistupuje do vlastního LHC. U pracovníků je navíc kontrolováno, zda porost, ke kterému přistupují, je v jejich středisku. 3.3 Architektura Pro implementaci byla zvolena vícevrstvá architektura, jak to ukazuje obrázek 3.1. Před celou aplikací jsou přeřazeny dva filtry, přes které prochází každý požadavek než se dostane ke zpracování dalšími vrstvami. 32

47 3.3. Architektura CorsFilter Zajišťuje odesílání správně nastavených hlaviček Access-Control-Allow-Origin, Access-Control-Allow-Methods a Access-Control-Allow-Headers, které umožňují JavaScriptu provádět požadavky na jinou doménu, což je z bezpečnostních důvodů zakázáno. Při ostrém nasazení není tento filtr potřeba, protože frontent i backend poběží na stejné doméně, ovšem pro vývoj je toto nastavení více než vhodné. AuthFilter Provádí prvotní autentizaci na základě hlaviček viz section:bezpecnost. Pokud se nepodaří totožnost subjektu ověřit vrací http status kód Unauthorized. JAX-RS Vrstva JAX-RS podle URL a HTTP metody určí, jaká metoda služby se má použít a v případě, že požadavek obsahuje data, postará se o převod na entity. Pokud se převod na entitu nezdaří (typicky špatný formát), popř. obslužná metoda služby má nekompatibilní parametry, vrátí JAX-RS chybový stavový kód. Service Vrstva obsahující většinu logiky. Stará se o získávání a ukládání dat z resp. do úložiště a jejich zpracováním. Úložiště Nejnižší vrstva aplikace. Je implementována pomocí JPA a stará se o persistenci dat v relační databázi MySQL. 33

48 3. Implementace Obrázek 3.1: Vrstvy aplikace 3.4 Reprezentace dat Jedním z největších problémů, se kterým jsem se v průběhu vývoje setkal, byl převod dat do JSONu tak, aby výsledek obsahoval pouze potřebná data. Často je například potřeba pouze seznam objektů a jejich ID, ale už ne často objemná data, která obsahuje. Standardně se při marchallingu rekurzivně prochází celá objektová struktura a všechny proměnné jsou postupně převedeny do nové reprezentace. Položka se nepřevádí pokud má hodnotu null a nebo pokud má Při implementaci jsem ale často narážel na to, že je nutné jeden objekt (resp. třídu) reprezentovat na různých místech různě. Prvním použitým řešením bylo objekt před každým převodem projít a všem nepotřebným proměnným nastavit hodnotu null. To bylo ovšem velmi pracné, nepřehledné a v neposlední řadě také neefektivní. Z toho důvodu jsem se rozhodl použít aspektově orientované programování (AOP), konkrétně rozšíření pro Javu, AspectJ[2]. Ta umožňuje navěsit na určitá místa volání vlastních metod. Zjednodušeně to funguje tak, že 34

49 3.4. Reprezentace dat napíšeme metodu, kterou chceme pouštět před každým voláním některých funkcí (tzv. aspekt), tyto funkce specifikujeme např. pomocí regulárního výrazu. Před kompilací programu AspectJ takovéto funkce vyhledá a navěsí na ně volání aspektů. Je možné specifikovat, zda chceme naši metodu volat před, po nebo tzv. around, tj. okolo, kdy volání cílové metody provádíme sami přímo v aspektu a můžeme se dokonce rozhodnout ji vůbec nezavolat nebo z ní vrátit jiný výsledek. Typickým vyžitím aspektů je např. logování nebo zabezpečení klíčových metod. Vytvořil jsem dvě První jmenovanou jsem označil atributy v entitách. Anotace jako parametr přijímá pole módů a slouží k vyznačení, při jakém z nich se má zobrazovat. Druhá anotace přijímá pouze jeden mód a označují se jí metody služby, čímž se určuje jaký mód je pro metodu aktivní. Následně už jen stačilo navěsit na gettery entit aspekt, který porovnává vykreslovací mód a módy atributu. Tento aspekt je volán around a proto, pokud není aktivní mód mezi módy atributu, může jednoduše vrátit null, což zajistí nevložení atributu do převedených dat. Obrázky 3.2 a 3.3 ukazují průběh volání před a po přidání aspektu. Obrázek 3.2: Bez aspektu Obrázek 3.3: S aspektem 35

50

51 Kapitola 4 Testování Testování je důležitou, často však u menších projektů opomíjenou, součástí softwarového vývoje. Objektivně zajišťuje všem zúčastněným stranám, že výsledná aplikace má deklarované vlastnosti a neobsahuje chyby 4. Testy rozlišujeme podle toho, zda známe vnitřní strukturu programu na tzv. black box a white box testy. Při black box testování přistupujeme k systému jako k černé skřínce a zkoumáme jeho chování na základě vstupů a výstupů bez znalosti implementace. To se hodí pokud potřebujeme systém otestovat z pohledu uživatele. Naopak při white box testech známe vnitřní strukturu a jsem pro schopni lépe odhadnout, kde hledat chyby. Tato metoda ovšem zastiňuje pohled uživatele. Dalším způsobem, jak dělit testy je podle úrovně, na které probíhají. Nejníže, na úrovni jednotlivých tříd se provádí jednotkové (unit) testy. Na začátku testu vytvoříme v izolaci instanci testované třídy a zkoušíme chování jejích veřejných metod. Jednotkové testování bývá občas znemožněno při nerespektování zásad Dependency Injection[16] (někdy také označované jako Inversion of Control). Ta stanoví, že třída by měla všechny své závislosti deklarovat buď jako parametry konstruktoru nebo jako parametry funkcí. Nikdy by neměla k jejich získání používat globální proměnné, statické metody nebo singletony. V případě porušení těchto zásad není možné při jednotkovém testu vytvořit izolovanou instanci a předat jí mockované závislosti. O úroveň výše stojí integrační testy, které verifikují systém na úrovni spolupráce jednotlivých komponent. V pozdějších fázích vývoje může být nasazeno systémové testování. Během těchto testů je aplikace ověřována jako funkční celek. Hotová aplikace je na straně zákazníka testována pomocí akceptačních testů. Testy lze také rozdělit podle toho, zda jsou automatizované nebo manuální. 4 Toto tvrzení samozřejmě platí pouze tehdy, když je testování bezchybné a úplné. 37

52 4. Testování Většinou se používá kombinace těchto metod, protože ne vše je možné otestovat automatickými testy. Manuální testy jsou ovšem zase nákladnější. 4.1 Testování systému Aplikace byla v průběhu vývoje podrobena několika druhům testů. Ihned po vytvoření logického celku jsem jeho funkčnost ověřil ručně. Takto je odhaleno největší množství chyb a jsou také nejrychleji opraveny. Takové to testování se někdy nazývá Assembly testing. Jednotkové testy jsem prakticky neprováděl, protože by kvůli převaze CRUD operací a absenci složitější logiky, testovali pouze databázovou vrstvu. Čas ušetřený na jednotkovém testování jsem investoval do funkčních testů. Na ty byl použit nástroj REST-Assured [24]. Ten umožňuje snadné testování RESTových služeb. Vzhledem k tomu, že existuje kompletní definice API webové služby, je možné napsat pro každou její část test. Typicky je přítomen test, který vytváří zdroj a následně kontroluje jeho správnost, když je vrácen ze systému. Poté je zdroj odstraněn, což má dva důvody. Za prvé je otestováno mazání zdroje a za druhé to zabraňuje hromadění testovacích dat v systému a připravuje to systém na opakované spuštění testu. Jak takovýto test vypadá je vidět v následujícím zdrojovém kódu 5 : public class VykonTest extends BaseTest public void test() { /* * Vytvoříme nový požadavek s testovacími daty * a odešleme ho na server. Kontrolujeme HTTP * status kód a z odpovědi získáme ID nového Výkonu. */ Integer id = given().body(data). expect().statuscode(200). body("kod", equalto(kod)). body("popis", equalto(popis)). put(url). path("id"); 5 Kód je zkrácen o import a definici konstant. 38

53 4.1. Testování systému /* * Podle ID z minulého kroku načteme * zdroj ze serveru a zkontrolujeme správnost dat. */ given().expect(). body("id", equalto(id)). body("kod", equalto(kod)). body("popis", equalto(popis)). get(url + id); } } /* * Nakonec zdroj odstraníme */ given().expect(). statuscode(204). delete(url + id); 39

54

55 Závěr Když mi byl tento projekt minulý rok navržen Petrem Gregorem jako téma mé bakalářské práce a byl jsem seznámen s jeho rámcovým rozsahem, říkal jsem si, že to bude relativně snadná práce. Z omylu jsem byl vyveden celkem brzo během úvodní analýzy a následné implementace. Z původně malého projektu byl najednou moloch, který nabobtnal na neuvěřitelných 19 tisíc řádek kódu. Ačkoli již aplikace pokrývá drtivou většinou požadavků, uvedení do ostrého provozu si vyžádá ještě spoustu úsilí a já se těším, že v jejím vývoji budu dále pokračovat i nad rámec školy. Mým osobním cílem bylo seznámit se s nějakou zajímavou technologií, kterou webové služby bezesporu jsou. Jsem rád, že aplikace nesklouzla do vyjetých kolejí a není jen další webovou stránkou napsanou v PHP za pomoci nějakého frameworku. Cílem této práce bylo vyvinout aplikaci pro Lesní hospodářskou evidenci a projít přitom od počáteční analýzy, přes kompletní návrh až k samotné implementaci. To se myslím podařilo, i když již nyní mám plány, jak aplikaci vylepšit. 41

56

57 Literatura [1] Change Vision: Astah. [cit ]. Dostupné z: net/ [2] Eclipse Foundation: AspectJ. [cit ]. Dostupné z: [3] Eclipse Foundation: EclipseLink Project. [cit ]. Dostupné z: [4] Facebook: HipHop for PHP: Move Fast. [cit ]. Dostupné z: 02/hiphop-for-php--move-fast/ [5] Gregor, P.: IS pro lesní hospodářskou evidenci - frontend. Bakalářská práce, České vysoké učení technické v Praze, Fakulta informačních technologií, Praha, [6] Haxx: Curl and Libcurl. [cit ]. Dostupné z: haxx.se/ [7] IFER - Monitoring and Mapping Solutions, s.r.o.: Lesní hospodářská evidence. [cit ]. Dostupné z: [8] The Internet Engineering Task Force: Request for Comments: [cit ]. Dostupné z: txt?number=4627 [9] ISSaR: Plocha lesů v procentech rozlohy státu. [cit ]. Dostupné z: 43

58 Literatura [10] IterSoft s.r.o. Choceň: Lesní a hospodářská evidence Výroba [cit ]. Dostupné z: html [11] iviz: Web application vulnerability statistics of [cit ]. Dostupné z: web-application-vulnerability-statistics-of-2012 [12] Java.net: Java API for RESTful Services. [cit ]. Dostupné z: [13] JBoss: Relational Persistence for Java. [cit ]. Dostupné z: [14] LesIS.cz: Cena řešení. [cit ]. Dostupné z: lesis.cz/cena_reseni [15] LesIS.cz: Informační systém LesIS. [cit ]. Dostupné z: http: // [16] Martin Fowler: Inversion of Control Containers and the Dependency Injection pattern. [cit ]. Dostupné z: martinfowler.com/articles/injection.html [17] Ministerstvo životního prostředí: Lesní zákon. [cit ]. Dostupné z: [18] Netbeans: NetBeans IDE. [cit ]. Dostupné z: netbeans.org/features/index.html [19] Nette.org: Nette Framework. [cit ]. Dostupné z: nette.org/ [20] Oracle: GlassFish - Open Source Application Server. [cit ]. Dostupné z: [21] PDS: PDS_ProPla. [cit ]. Dostupné z: produkty-a-reseni/lesnictvi/lesni-hospodarska-evidence [22] Project JAXB: JAXB RI Binding Compiler (xjc). [cit ]. Dostupné z: [23] REST API Tutorial: Using HTTP Methods for RESTful Services. [cit ]. Dostupné z: lessons/httpmethods.html 44

59 Literatura [24] REST Assured: Java DSL for easy testing of REST services. [cit ]. Dostupné z: [25] Tigris: ArgoUML. [cit ]. Dostupné z: tigris.org/ [26] UHÚL: Informační standard lesního hospodářství pro LHP a LHO. [cit ]. Dostupné z: standart.php [27] UHÚL: VYHLÁŠKA Ministerstva zemědělství ze dne 18. března 1996 o lesním hospodářském plánování. [cit ]. Dostupné z: http: // [28] W3C: Extensible Markup Language (XML) 1.0 (Fifth Edition). [cit ]. Dostupné z: [29] W3C: SOAP Specifications. [cit ]. Dostupné z: w3.org/tr/soap/ [30] W3Techs: Historical trends in the usage of server-side programming languages for websites. [cit ]. Dostupné z: com/technologies/history_overview/programming_language [31] W3Techs: Usage statistics and market share of PHP for websites. [cit ]. Dostupné z: details/pl-php/all/all [32] Wiegers, K.: Požadavky na software. Brno: Computer Press, 2008, ISBN [33] Wikipedia: Representational state transfer. [cit ]. Dostupné z: transfer [34] Wikipedia: Web API. [cit ]. Dostupné z: wikipedia.org/wiki/web_api [35] Zend: Zend Framework. [cit ]. Dostupné z: framework.zend.com/ 45

60

61 Příloha A Seznam použitých zkratek CRUD DIL ETZ JAX-RS JSON LHC LHE LHP ODD POR PSK REST SOAP XML API HTTPS JAXB JPA Create, read, update and delete Dílec Etáž Java API for RESTful Web Services JavaScript Object Notation Lesní hospodářský celek Lesní hospodářská evidence Lesní hospodářský plán Oddělení Porost Porostní skupina Representational State Transfer Simple Object Access Protocol Extensible Markup Language Application Programming Interface Hypertext Transfer Protocol Secure Java Architecture for XML Binding Java Persistance API 47

62

63 Příloha B Obrázky Obrázek B.1: Výrobně-mzdový lístek 49

64 B. Obrázky Obrázek B.2: Use Case diagram 50